* Grammar issue

* Naming consistency
* Optional redirect URL for QR flow (POS scenario)

dips/dip-158.md

@@ -65,9 +65,9 @@ Content:
 ---
 The high-level flow of an eCommerce P2M payment (regardless of the type) is:
 1. On the merchant's checkout page the customer chooses to pay with Diem
-2. The merchant transmits the payment details to its VASP (merchant's VASP) so the latter can generate and a payment request with Diem  
-3. The merchant's VASP (the receiver) generates a payment request with all details needed to identify this payment later in the process, provides it to the merchant and makes it available to the customer's Diem wallet (the customer's VASP or sender)
-4. The customer's VASP parses the payment request (e.g. by scanning the payment request QR) and uses the provided payment identifier to get the payment details. This is the first step of the off-chain protocol
+2. The merchant transmits the payment details to its VASP (receiver VASP) so the latter can generate a payment request with Diem  
+3. The the receiver VASP generates a payment request with all details needed to identify this payment later in the process, provides it to the merchant and makes it available to the customer's Diem wallet (the customer's VASP or sender)
+4. The sender VASP parses the payment request (e.g. by scanning the payment request QR) and uses the provided payment identifier to get the payment details. This is the first step of the off-chain protocol
 5. The wallet then presents the requested payment details to the customer so the customer can review the payment
 6. The customer approves the payment request in the wallet
 7. The wallet initializes the payment protocol (off-chain) which will end (if successful) with the funds being authorized or charged (depending on the payment type). Successful completion implies that the receiving VASP was satisfied with the payer information provided and the sender VASP was satisfied with the merchant information provided. **Note** that if the payment amount exceeds the amount that requires a dual attestation signature to be submitted to the blockchain, it must be part of the on-chain transaction submitted  
@@ -109,12 +109,12 @@ The following is a list of new values for the `command_type` field of the `Comma
 
 | Command Type |Direction| Description | Request Data | Response Data |
 |-|-|-|-|-|
-|GetInfoCommand|Sender > Receiver|By providing the object reference id the wallet can retrieve the object information from the receiving VASP. In most cases, this would be the first command sent by the wallet. The wallet is not expected to provide any payer data at this stage|Reference ID|Payment Details ; Merchant Data|
-|InitChargeCommand|Sender > Receiver|This functionality allows the wallet to init the payment process based on the payment details. For example, this may occur after the customer approved the payment request|Reference ID ; Payer Data|Optional recipient signature|
+|GetInfoCommand|Sender > Receiver|By providing the object reference id the wallet can retrieve the object information from the receiving VASP. In most cases, this would be the first command sent by the wallet. The wallet is not expected to provide any payer data at this stage|Reference ID|Payment Details ; Business Data|
+|InitChargeCommand|Sender > Receiver|This functionality allows the wallet to init the payment process based on the payment details. For example, this may occur after the customer approved the payment request|Reference ID ; Payer Data|Optional Recipient Signature|
 |InitAuthorizeCommand|Sender > Receiver|This functionality allows the wallet to init the payment process based on the payment details. For example, this may occur after the customer approved the payment request|Reference ID ; Payer Data||
 |ReadyForSettlementNotification|Sender > Receiver|This functionality allows the wallet to indicate the payment is ready for settlement. The wallet is expected to submit a transaction on-chain immediately before or after declaring it is ready|Reference ID||
 |AuthorizedNotification|Sender > Receiver|This functionality allows the wallet to indicate funds are locked for future capture. Relevant only for Auth / Capture payments|Reference ID||
-|CaptureCommand|Receiver > Sender|This functionality allows the receiver to capture the locked (authorized) funds. Relevant only for Auth / Capture payments. This optionally includes the recipient signature for dual attestation scenario if needed|Reference ID||
+|CaptureCommand|Receiver > Sender|This functionality allows the receiver to capture the locked (authorized) funds. Relevant only for Auth / Capture payments. This optionally includes the recipient signature for dual attestation scenario if needed|Reference ID ; Optional Recipient Signature||
 |VoidCommand|Receiver > Sender|This functionality allows the receiver to void the payment. For example, the merchant voided the payment because the purchased products are out of stock. Relevant only for Auth / Capture payments|Reference ID||
 |AbortCommand|Sender > Receiver / Receiver > Sender|This functionality allows both parties to abort the payment. For example, the receiver may want to abort the payment following failed risk checks|Reference ID||
 
@@ -770,6 +770,7 @@ The table below specifies the fields that should be encoded into the QR code dee
 |-----|----|---------|-----------|
 |vasp_address|str|Y|Address of receiving VASP. The address is encoded using bech32. For Diem addresses format, refer to the "account identifiers" section in [DIP-5](https://dip.diem.com/dip-5/#account-identifiers).|
 |reference_id|str|Y|A unique identifier of this payment. It should be a UUID according to RFC4122 with "-"'s included.|
+|redirect_url|str|N|Encoded URL used by the wallet to redirect the customer back to the merchant|
 
 For example, for the following values: