diff --git a/.gitbook.md b/.gitbook.md index cc985e5..05d5b1b 100644 --- a/.gitbook.md +++ b/.gitbook.md @@ -16,13 +16,13 @@ `npm run gitbook:serve` -## Generate PDF +## Generate PDF - option 1 ### Prerequisites 1. Install Calibre: https://calibre-ebook.com/download -2. npm install svgexport -g" +2. npm install svgexport -g 3. Pre-requisites for node-canvas: https://github.com/Automattic/node-canvas/wiki/_pages @@ -32,13 +32,27 @@ A file `book.pdf` will be generated in the root directory -## Known Issues +### Known Issues - `npm install` fails for the `gitbook-pdf` dependency. Here is a work-around: https://github.com/GitbookIO/gitbook-pdf/issues/23 - removed `"gitbook-pdf": "^0.0.2",` as a dependency from package.json. Please manually install `gitbook-pdf` until the issue can be resolved - Export PDF does not contain a +## Generate PDF - option 2 +1. Install Pandoc `brew install pandoc` + +2. Verify version `pandoc --version` _requires to be vresion 2.0 or higher_. + +3. install pdf engine `brew install Caskroom/cask/wkhtmltopdf`. _Version 0.12.4 or higher_. + +4. Acquaint yourself with Pandoc `https://pandoc.org/MANUAL.pdf` + + Also see https://github.com/mszep/pandoc_resume#requirements + +5. Run the following to generate the PDF using html5 output `pandoc -t html5 -s {input} -o {output} --pdf-engine=wkhtmltopdf` + + Replace {input} and {output} with the file names. ## Docker ### Build diff --git a/documents/platform-operating-guideline.md b/documents/platform-operating-guideline.md index 52c1ad1..a4746ff 100644 --- a/documents/platform-operating-guideline.md +++ b/documents/platform-operating-guideline.md @@ -4,6 +4,7 @@ - Author: Carol Coye Benson (Glenbrook), Michael Richards (ModusBox) - Date: October 2019 - Description: + --- ## **About the Mojaloop Community Business Document Project** @@ -130,18 +131,17 @@ Some rules and operational specifications vary by Use Cases and Secondary Use Ca The Scheme supports certain Identifiers, or payment addresses, for use in making Transfers. The Identifier identifies the Payee whose Transaction Account is credited for the Transfer. Supported Scheme Identifiers are listed in an Appendix to the Business Rules. -__ + _For each scheme supported identifier, this document should specify what the identifier is and how it is resolved (how it is determined which Payee DFSP is responsible for the transaction account associated with that identifier._ #### 1.4.1 Example: The MSISDN Identifier -__ + _Each scheme will have its own guidelines for each identifier; the provisions below could vary significantly depending on choices made._ - MSISDN's are mobile numbers which are globally unique. MSISDN's are the Transaction Account Identifier for DFPSs who are Mobile Network Operators and who are providing Transaction Accounts to their customers. - Use of the MSISDN as a Payee Identifier is limited to Transaction Accounts provided by DFSPs who are the Mobile Network Operator responsible for that MSISDN. - __ + _Note: if MSISDN's are used for other Transaction Accounts, they are aliases, and a separate protocol for resolving them must be specified._ - A Party Request for an MSISDN is resolved by a MSISDN directory service determined by the Scheme. The Scheme may specify directory service maintenance obligations for Mobile Network Operator DFSPs from time to time. @@ -519,13 +519,13 @@ following sections:_ ## 8. Appendix: Scheme Supported Use Cases and System Parameters -__ +_This is the same table as appears in the Business Rules document, but it has added the systemic codes necessary for the Platform to recognize a transaction as belonging to a given use case or secondary use case. A scheme would only define Secondary Use Cases if it wanted to write rules and/or specify fees that are unique to that Secondary Use Case_ -__ +_This table is an example of a table of Use Cases and Secondary Use Cases that a scheme might support._ | Use Case Code | Use Case | Secondary User Case | Required Data Elements | Other Methods of Use Case Determination | -| --- | --- | --- | --- | --- | -| 1.0 | P2P | Person to Person | API Setting
Scenario=Transfer

Initiator = Payer

Initiator Type = Consumer

Recipient Type = Consumer
| | +| :--- | :----- | :--------- | :-------------------------- | :------------------------------------------- | +| 1.0 | P2P | Person to Person | API Setting
Scenario=Transfer

Initiator = Payer

Initiator Type = Consumer

Recipient Type = Consumer
| | | 1.1 | P2P | Wallet to wallet | Transaction Account Type for Payer DFSP is Wallet and for Payee DFSP is Wallet | | 1.2 | P2P | Bank to bank | Transaction Account Type for Payer DFSP is Bank and for Payee DFSP is Wallet | | 1.3 | P2P | Wallet to bank | Transaction Account Type for Payer DFSP is Wallet and for Payee DFSP is Bank | diff --git a/documents/scheme-business-rules.md b/documents/scheme-business-rules.md index d6a508f..5d378ae 100644 --- a/documents/scheme-business-rules.md +++ b/documents/scheme-business-rules.md @@ -4,6 +4,7 @@ - Author: Carol Coye Benson (Glenbrook) - Date: October 2019 - Description: + --- ## **About the Mojaloop Community Business Document Project** @@ -352,7 +353,6 @@ Section Headings and bulleted entries underneath section headings are actual pro - The investigation and report, as well as remedies that may be required will be held confidential to the extent permitted by Applicable Law. ### 8.2 Risk Management Policies ------------------------- @@ -436,8 +436,8 @@ Scheme Services include: -| | Use Case | Secondary Use Case | -| --- | -------- | ------------------ | +| | Use Case | Secondary Use Case | +| :---: | :--------: | :-------------------------- | | 1.0 | P2P | Person to Person | | 1.1 | P2P | Wallet to wallet | | 1.2 | P2P | Bank to bank | diff --git a/documents/scheme-key-choices.md b/documents/scheme-key-choices.md index 99df4ca..e61ff3d 100644 --- a/documents/scheme-key-choices.md +++ b/documents/scheme-key-choices.md @@ -4,6 +4,7 @@ - Author: Carol Coye Benson (Glenbrook) - Date: October 2019 - Description: + --- ## **About the Mojaloop Community Business Document Project** @@ -226,15 +227,13 @@ Any scheme implementing credit-push payments needs to specify how the payer and - A scheme may also use a broadcast method to determine the DFSP responsible for a given payment address ("do you claim this address"), but needs to develop a protocol to manage conflicts if more than one DFSP "claims" the address. -- It is important to note that the resolution method can different for each type of supported payment address. Some supported payment address types may also be accompanied by particular data sets: for - example, when a payment is being made in payment of an invoice, the payment address may be some type of alias, and that use of that alias may be tied to accompanying invoice data. Dynamic QR codes, as an example, will create a "request to pay" that may contain the scheme-supported merchant ID (an alias) and accompanying transaction data detail. +- It is important to note that the resolution method can different for each type of supported payment address. Some supported payment address types may also be accompanied by particular data sets: for example, when a payment is being made in payment of an invoice, the payment address may be some type of alias, and that use of that alias may be tied to accompanying invoice data. Dynamic QR codes, as an example, will create a "request to pay" that may contain the scheme-supported merchant ID (an alias) and accompanying transaction data detail. The Open API specification and the Mojaloop reference code support a wide range of different address types: mobile number, bank account, national ID, aliases ("Quickshop\@abc"), etc. ### 7.1 L1P Alignment -- Payments Addressing -Secure, easy payment addressing relates to two important concepts in Level One: convenience for the end-user and "openness". The latter is particularly important to enable competition and rapid scaling of a -payment system. As schemes (Level One and otherwise) worldwide struggle to determine how to best solve the question of payments addressing, a few best practices appear to be emerging: +Secure, easy payment addressing relates to two important concepts in Level One: convenience for the end-user and "openness". The latter is particularly important to enable competition and rapid scaling of a payment system. As schemes (Level One and otherwise) worldwide struggle to determine how to best solve the question of payments addressing, a few best practices appear to be emerging: - Although the use of the mobile number, in particular, as an address has an obvious appeal, there appears to be a trend to use aliases -- identifiers with no additional meaning. This is demonstrated in India with the UPI system and in Australia's new real-time system, where the identifier is referred to as the PAYID. diff --git a/documents/scheme-participation-agreement.md b/documents/scheme-participation-agreement.md index c4250e6..54c0729 100644 --- a/documents/scheme-participation-agreement.md +++ b/documents/scheme-participation-agreement.md @@ -4,6 +4,7 @@ - Author: Carol Coye Benson (Glenbrook) - Date: October 2019 - Description: + --- ## **About the Mojaloop Community Business Document Project** diff --git a/documents/scheme-uniform-glossary.md b/documents/scheme-uniform-glossary.md index 0c4aec0..b0a955e 100644 --- a/documents/scheme-uniform-glossary.md +++ b/documents/scheme-uniform-glossary.md @@ -4,6 +4,7 @@ - Author: Carol Coye Benson (Glenbrook) - Date: October 2019 - Description: + --- ## **About the Mojaloop Community Business Document Project** @@ -32,8 +33,8 @@ This is a glossary of terms used in the Mojaloop Business Community Document Pro # Uniform Glossary Template -| **Term** | **Definition** | -| --- | --- | +| Term | Definition | +| :----- | :---------------------------------------------------------------------------------------------- | | Access Channel | Places or capabilities that are used to initiate or receive a payment. Access channels can include bank branch offices, ATMs, terminals at the POS, agent outlets, mobile phones, and computers. | | Account Lookup | A process that determines the DFSP responsible for a Transaction Account | | Account Lookup System | Account Lookup System is an abstract entity used for retrieving information regarding in which FSP an account, wallet or identity is hosted. The Account Lookup System itself can be hosted in its own server, as part of a financial switch, or in the different FSPs. | diff --git a/package.json b/package.json index 5792c85..a751e22 100644 --- a/package.json +++ b/package.json @@ -1,6 +1,6 @@ { "name": "mojaloop-business-docs", - "version": "8.5.3", + "version": "8.7.0", "description": "Mojaloop Business Documentation GitBook Project", "dependencies": { "express": "4.17.1", diff --git a/supporting-documents/PDFs/platform-operating-guideline.pdf b/supporting-documents/PDFs/platform-operating-guideline.pdf new file mode 100644 index 0000000..d406dc8 Binary files /dev/null and b/supporting-documents/PDFs/platform-operating-guideline.pdf differ diff --git a/supporting-documents/PDFs/scheme-business-rules.pdf b/supporting-documents/PDFs/scheme-business-rules.pdf new file mode 100644 index 0000000..e58a7c7 Binary files /dev/null and b/supporting-documents/PDFs/scheme-business-rules.pdf differ diff --git a/supporting-documents/PDFs/scheme-key-choices.pdf b/supporting-documents/PDFs/scheme-key-choices.pdf new file mode 100644 index 0000000..a87b3de Binary files /dev/null and b/supporting-documents/PDFs/scheme-key-choices.pdf differ diff --git a/supporting-documents/PDFs/scheme-participation-agreement.pdf b/supporting-documents/PDFs/scheme-participation-agreement.pdf new file mode 100644 index 0000000..92fbf1b Binary files /dev/null and b/supporting-documents/PDFs/scheme-participation-agreement.pdf differ diff --git a/supporting-documents/PDFs/scheme-uniform-glossary.pdf b/supporting-documents/PDFs/scheme-uniform-glossary.pdf new file mode 100644 index 0000000..3b2f2a0 Binary files /dev/null and b/supporting-documents/PDFs/scheme-uniform-glossary.pdf differ