Updated to use the latest theme, reworded and fixed formatting

README.md

@@ -4,17 +4,53 @@
   <p align="center">Template project to use for creating client merchant docs</p>
 </p>
 
+## Requirements
+
+- GIT
+- Hugo (v0.100.2 extended)
+
 ## Usage
 
 ### Download/Clone
 
-The documentation uses a submodule for its theme. Therefore when cloning the repository ensure you do so recursively:
+The client docs template uses a GIT submodule for its theme. Therefore, when cloning the repository ensure you do so recursively:
+
+```sh
+git clone --recurse-submodules [email protected]:rehive/client-docs-template.git
+```
+
+When pulling new changes from `master` make sure you also run the following afterwards to get the latest submodule updates.
 
 ```sh
-git clone --recurse-submodules [email protected]:rehive/docs-portal.git
+git submodule update
 ```
 
+If a submodule has been updated at its origin, then you will need to merge these updates into the repository using:
+
+```sh
+git submodule update --remote --merge
+```
+
+And then commit/push the new submodule.
+
 ### Development
 
+To run the hugo server:
+
 ```sh
 hugo serve
+```
+
+To build the static files:
+
+```sh
+hugo
+```
+
+Please take a look at the [Hugo Documentation](https://gohugo.io/documentation/) for additional usage.
+
+### Configuration
+
+Update the configuration in the `config.yaml` with apropriate values.
+
+Update the `references` in the `content/checkout/_index.md` file.

config.yaml

@@ -3,24 +3,32 @@ languageCode: "en-us"
 title: "Documentation"
 theme: "hexon-hugo-theme"
 
+markup:
+  highlight:
+    style: "dracula"
+  goldmark:
+    renderer:
+      unsafe: true
+
 params:
   companyName: ExampleCompany
   companyId: example_company
   appUrl: https://wallet.example.com
   invoicesApi: https://api.invoices.example.com
   businessApi: https://api.business.example.com
+
   logoUrl: https://example.com
-  logoImage: https://rehive.s3.amazonaws.com/companies/2458/logos/6c4d8de546d74b30a3d19c78fb42ec16_1611825066.png
-  heroImage: https://rehive.s3.amazonaws.com/companies/2458/logos/6c4d8de546d74b30a3d19c78fb42ec16_1611825066.png
-  favicon: https://rehive.s3.amazonaws.com/companies/2458/logos/6c4d8de546d74b30a3d19c78fb42ec16_1611825066.png
+  logoImage: /images/logo.svg
+  heroImage: /images/hero.svg
+  favicon: /images/favicon.png
 
-  primaryColor: "#002d6d"
-  secondaryColor: "#ff2852"
+  primaryColor: "#5336FF"
+  secondaryColor: "#A4A5F5"
 
   extraNavItems:
-    - title: Log in
+    - title: Sign in
       url: https://wallet.example.com
 
   extraFooterItems:
-    - title: Log in
+    - title: Sign in
       url: https://wallet.example.com

content/checkout/_index.md

@@ -4,4 +4,9 @@ title: Merchant checkout
 description: Merchant checkout API documentation.
 weight: 1
 linkTo: /checkout/get-started/introduction
+references:
+  - title: Platform API Reference
+    url: https://rehive-platform.redoc.ly
+  - title: Platform Admin API Reference
+    url: https://rehive-platform-admin.redoc.ly
 ---

content/checkout/core-resources/invoice.md

@@ -8,6 +8,7 @@ weight: 1
 The Invoice the core resource that encapsulates all logic around receiving user payments. All other resources are associated with the Invoice in various ways. 
 
 ### Statuses
+
 The statuses of an invoice will tell you whether or not the user has paid, underpaid, overpaid etc and is the primary mechanism for triggering third party logic on your end.
 
 status | description
@@ -25,7 +26,7 @@ cancelled | The invoice has been set to cancelled by a manager.
 
 ### Object
 
-```
+```json
 {
     "id": "deb62287-dbc6-4f11-8f83-d753f6cf1284",
     "user": {

content/checkout/core-resources/payment-processor.md

@@ -13,7 +13,7 @@ Each payment processor has a unique subtype and identifier field
 
 ### Object
 
-```
+```json
 {
     "id": "b5950a31-f954-44ff-8860-3a18d7349cf5",
     "unique_string_name": "native",

content/checkout/core-resources/quotes.md

@@ -9,7 +9,7 @@ The Quote object contains the amount and currency the Payment Processor expects
 
 ### Object
 
-```
+```json
 {
     "id": "27fd41af-279e-44e7-b384-d6a6fe54f160",
     "request": 16,

content/checkout/core-resources/transactions.md

@@ -9,7 +9,7 @@ A Transaction object returned matches the structure of a {{<param companyName>}}
 
 ### Object
 
-```
+```json
 {
     "transaction_code": "459b3407-3009-4f77-bbbf-5d6e12788958",
     "settled": false,

content/checkout/custom-integration/closed-loop.md

@@ -8,6 +8,7 @@ weight: 5
 Closed-loop payments involve the user paying directly from their wallet balance to your merchant account. There are a few options available to the ender user but each work in a very similar way. The options you should present to the user if they chose to pay with their wallet balance are as follows, any can be omitted depending on what you would like to support:
 
 ### Scan to Pay and Login to Pay
+
 To be added.
 
 ### OTP payment
@@ -19,14 +20,16 @@ The required information from the user is:
 2. A mobile number that validated on their wallet
 
 Once the user has provided this information you will need to PATCH the Invoice as follows:
-```
+
+```sh
 curl -X PATCH "{{<param invoicesApi>}}/api/requests/<invoice-id>/" -H "accept: application/json" 
 -H "Content-Type: application/json" 
 -d "{ \"payer_email\": \"[email protected]\", \"payer_mobile_number\": \"+27777777777\"}"
 ```
 
 If successful the user will receive an SMS with the OTP code. You will need to provide a way for the user to enter this code so you can make a POST request to: `{{<param invoicesAPI>}}/api/manager/businesses/<business_id>/invoice/<invoice-id>/otp-challenge/` as follows:
-```
+
+```sh
 curl -X POST "{{param invoicesApi}}/requests/<invoice-id>/otp_challenge/" 
 -H "accept: application/json" -H "Content-Type: application/json" --data '{"otp": "401703"}'
 ```

content/checkout/custom-integration/invoicing.md

@@ -8,9 +8,11 @@ weight: 2
 An invoice encapsulates the entire payments process. Once the customer has selected {{<param companyName>}} as a payment option the next step is for your system to generate a {{<param companyName>}}  invoice for their payment.
 
 ### Create the invoice
+
 The first step to initiate the payment process is to create an invoice. This would usually be done once the user has selected {{<param companyName>}} as the payment option for the order they wish to pay for.
 
 ##### The core pieces of information required to create an invoice are:
+
 1. The total amount to be paid in your base currency
 2. Return url: When the user has completed their off-site payment this is the url they should be redirected back to.
 3. An optional “reference” field which ideally should match an identifier for your order within your e-commerce system
@@ -23,7 +25,8 @@ URL | methods
 `{{params businessApi}}​/api/manager​/businesses​/{business_id}​/invoices​/` | `POST`
 
 ### Example data:
-```
+
+```json
 {
   "request_reference": "MY_ECOMMERCE_REFERENCE",
   "request_amount": 10000, # Value of invoice in cents
@@ -35,7 +38,8 @@ URL | methods
 ```
 
 ### Example success response:
-```
+
+```json
 {
   "id": "e7d7a5a2-9a97-4930-a992-589a6133488f",
   "user": "{}", # User object

content/checkout/custom-integration/open-loop.md

@@ -8,11 +8,12 @@ weight: 4
 Open loop payments are any non-wallet balance payments made. These are usually deposits from an external value such as a crypto currency, credit card or bank payment. 
 
 ### Displaying payment information
+
 The display of the payment information can depend on how the payment processor handles payments. Each payment processor quote will contain a different set of payment details. The relevant quote to display to the user will be the one with the matching payment processor to the `primary_payment_processor` field.
 
 Within the quote objects on the Invoice there will be a few fields(NOTE: this reference is different to the Invoice reference): 
 
-```
+```json
   "reference": "459b3407-3009-4f77-bbbf-5d6e12788958",
   "deposit_details": {},
 ```
@@ -23,7 +24,7 @@ The deposit details are any extra information such as: Another unique crypto ide
 
 For each open-loop processor you support these two fields should be displayed appropriately to the user paying. Using Bitcoin as an example your Quote fields might look like this:
 
-```
+```json
   "reference": "12CsH7h4ro5R8p3FwEAhKZHUEddz1ZfseV",
   "deposit_details": {},
 ```
@@ -33,21 +34,27 @@ The reference is the Bitcoin address generated for this deposit which the user p
 ### Handling statuses
 
 ##### Processing
+
 The user has chosen a payment processor. In certain open-loop cases you might want to poll the `{{params businessApi}}/api/manager/businesses/<business_id>/invoices/<invoice-id>/transactions/` endpoint to check for new deposits being made. This is particularly important in the case of crypto deposits waiting for confirmations.
 
 ##### Paid
+
 If the amount sent by the user matches the quoted amount exactly the entire Invoice will be set to the Paid status. Once this has happened you can assume the funds have been received and processed. Any order statuses on your e-commerce platform can be set to their Completed states.
 
 ##### Overpaid
+
 The user has paid more than the quoted amount. This can be handled by Completing any outstanding orders associated with the payment and then refunding the user with the difference between the Quoted amount and the Paid amount.
 
 ##### Underpaid
+
 An underpaid Invoice will require the user to make another transaction for the remaining balance. The difference in the quote fields of `amount` and `total_paid` should be displayed clearly to the user as well as the deposit details for making the outstanding payment.
 
 ##### Expired
+
 Any requests that expire are no longer usable and a new Invoice will need to be created with the same fields as the expired one.
 
 ### Displaying processing Crypto transactions
+
 One of the unique aspects about cryptocurrency is transactions often need to be confirmed multiple times before they can be considered completely irreversible. This means that a user might make a deposit to pay for an Invoice but the invoice will only Complete once the transaction associated with it Complete/is confirmed. You will want to display this to the user so they know they have a pending successful transaction.
 
 To display this information you will use the transactions endpoint of the invoice: `{{<param businessApi>}}/api/manager/businesses/<business_id>/invoices/<invoice-id>/transactions/`.
@@ -56,7 +63,7 @@ While an Invoice is in the “Processing” state and a relevant crypto payment
 
 An example of a request with transactions:
 
-```
+```json
 {
   "status": "success",
   "data": [

content/checkout/custom-integration/payment-quotes.md

@@ -15,7 +15,8 @@ Once a payment method has been selected the Invoice will return with a relevant
 
 
 #### Payment processor object example:
-```
+
+```json
 {
   "id": "27fd41af-279e-44e7-b384-d6a6fe54f160",
   "request": 16,

content/checkout/custom-integration/payments.md

@@ -11,7 +11,8 @@ Selecting a payment method
 Each invoice requires a user to select a valid payment method. A list of supported methods for a specific invoice can be found in the `available_payment_processors` array on the Invoice object. They are uniquely identified by a `unique_string_name` field. This list is also the one you have defined when setting up the Merchant configuration settings.
 
 #### Payment processor object example:
-```
+
+```json
   {
     "id": "19dff821-a349-4bbc-a929-72bf9fcef4d1",
     "unique_string_name": "native_otp",
@@ -29,7 +30,7 @@ The only piece of information required from the user is a valid email address to
 
 Once the user has made their choice and entered an email address your backend or front-end should update the Invoice object by PATCHing the `primary_payment_processor` field with the `unique_string_name` of the payment processor using the anonymous endpoint like so:
 
-```
+```sh
 curl -X PATCH "{{<param invoicesApi>}}/api/requests/<request_id>/" 
 -H "accept: application/json" -H "Content-Type: application/json" 
 -d "{ \"primary_payment_processor\": "native_otp"}"