Settlement Reconciliation over beckn protocol

[venkatramanm]

Settlement Model 1 - Bap collects money. (Prepaid)

/on_init sends the payment details of the account to be settled on the protocol.

• BAP collects money in nodal account.
• BAP keeps its share,
• Transmits network fee to gw's account (possibly hard coded)
• Transmits seller_share to account information transmitted in /on_init
• Calls a Signed /paid api on gw and /paid on bpp separately
  with Payment Txn Details and amount.
• gw and bpp can do the following.
  • Send ACK
  • check for expected entry based on their logs and bank statement. either using API or manually.
  • sends /on_paid api call with the same Payment Transaction details from its side. With either error ( not received ) or a message (received)
• BAP ACKs it and marks its transaction_id as settled once it has received and acknowledged /on_paid from BPP and BG with success.
• Some times there are delays in transmission and once received in the BPP side, BPP would send /on_paid with success.

For all other payment models

Protocol today allows only transmitting bpp's payment details to bap as part of /on_init. BAP's and GW bank details are not sent via protocol today. So Settlerment information are not symmetrically available for any one to be able to collect settle.

Reconciling ledgers via beckn

Beckn Protocol changes

Skip Sending payment info of bpp in /on_init

/get_payment_info

Implemented by all participants (BPP, BAP, BG) 
 passing transaction_id  

/payment_info

Send Bank/UPI Details of the participant that the transaction needs to be credited for. 

So the collecting entity
Calls /get_payment_info on all other entities party to a transacation ( bg, bpp, bap )
Based on the order_amount as part of confirm, computations of commissions / fees are done based on network policy for each participant and inserted into a table,

transaction_id	Date	Subscriber_id	amount	Settled
1	01-01-2023	bap	3	N
1	01-01-2023	bg	1.5	N
1	01-01-2023	bpp	3.5	N
1	01-01-2023	provider	92	N

then the collected party, calls

/paid
Passing Payment Transaction Details Array

{ payment : {
	txn_id : "" ,
	amount : "",
	paid_at :"" , // date-time
	transaction_ids: ["1","2"...]
}}

Indicates payment made by caller to receiver.

/on_paid
The other party checks bank account with api or manually verifies based on expected entry with the payment transaction_id across all listed transactions and breakup, Calls on the calling party and informs error or success.

Once each pair of parties sign off, the entry in the table is marked as Settled:"Y" against the respecting records making it ready for next day's process.

similarly the party calling /on_paid may maintain receivable information which will be squashed after sending /on_paid api.

[ravi-prakash-v]

Can we list down all payment use cases before concluding that a new API is needed?

We cannot be adding new APIs without stress testing the current protocol. And if it has been stress tested, there has to be a explicit report that says, "these use cases are not supported by the current protocol, and even modification of the current APIs does not seem to help, hence we need a new API."

In a larger context, we should formalize this process as part of the protocol governance.

[venkatramanm]

We only have ability to pass seller/seller app a/c details in on init.

We don't have ability to pass a/c details of bg and bap in the protocol. This asymmetry prevents payment collected by seller or logistics partners to be settled with others easily.

[venkatramanm]

If we don't want to do any thing on this, we can remove the on init passing of payment url too. It looks like incomplete thought given on payment and settlement front.

If we have an alternative idea of modifying existing APIs to pass bg and bap a/c details. , Lets discuss that too.

[venkatramanm]

A solution with registry was a possibility but that may not support dynamic accounts based on provider(if provider is paid directly) unless providers are absorbed in registry.

Absorbing providers may also not be that far fetched as service regions( in a way proxy for provider locations) are being considered to be taken into registry for search optimization.

[venkatramanm]

@pramodkvarma any thoughts?

[pramodkvarma]

It's important to have account info (normalized URI format like UPI VPA, use same normative representation) within the transaction. It allows different accounts to be used for different types of transactions etc. Neither hard coding nor registries work.

[venkatramanm]

Usecases attempted to be addressed

1. Settle with bg(s) by the payment collector (bap or bpp)
2. Settle with bap(s) if seller app collects payment.