How to capture multiple payment actions during an ev charging session?

[ameetdesh]

How to capture consecutive payments actions during an ev charging session. e.g. consider a EV charging session where a slot has been reserved.

• Customer pays initial advance: COMPLETED at 150 ₹
• 20% of amount was not used. So REFUND of 30 ₹
• or the charger did not when balance was over, resulting in an overcharge collection: COMPLETED of 45 ₹

++ @biodatanet

@ravi-prakash-v can you respond.

[ravi-prakash-v]

TL;DR

The edges capture the payment actions via either,
a) confirm/on_confirm, if the payment needs to be done to create the order, or
b) update/on_update, if the payable amount gets recalculated after the creation of the order

Detailed Answer

To answer this question, we need to understand and appreciate two facts:

1. Beckn Protocol is stateless. It does NOT carry history. Therefore, the state of a transaction SHOULD be preserved at the edges, NOT in the message. The BAP and the BPP MUST use various Beckn API calls to synchronize the state of an order between each other.
2. The actual act of payment, i.e, the settlement, happens off the fabric, sometimes even at times out of sync with the actual ongoing transaction. using existing payment infrastructures like PGs, Bank transfer, Credit card networks, wallets, Payment DPIs (like UPI), government schemes, vouchers, redemption, etc.

Now, the actual payment action can happen at any checkout terminal i.e. the BAP's checkout page, The BPP's payment gateway page, or at the charging point via a card machine, or a UPI QR code at the charging point, etc. To bring the control back to the Beckn API layer, both the BAP and the BPP need to record this off-network action back into the order and synchronize state.

Keeping these two principles in mind, we can now derive a generalized technical problem based on the business use case presented.

The problem

How do a BAP and BPP synchronize on the latest state of an action (like Payment) that has happened off the value-exchange layer, i.e, the fabric?

The solution

Now, let's analyze the three actions that were described namely,

1. Customer pays initial advance: COMPLETED at 150 ₹

• This action typically happens between on_init and confirm.
• The BAP receives the payment terms via on_init along with some settlement locations like bank account details, UPI ID, SWIFT code, or a Payment Gateway link.
• The BAP then invokes the first checkout flow.
• In case the BPP sends a PG link, the BAP enables the user to click on the link and redirects them to the BPP's payment page on their browser.
• While the user's focus is currently in the browser, the BAP MAY show a loader waiting for payment confirmation page on its UI.
• Once the payment (or the promise of payment) has been received and/or verified by the BPP, the BPP SHOULD go ahead and create the order, generate an order ID and send an on_confirm callback with the latest status of payment as 'PAID' along with the other details of the order
• Upon receiving an asynchronous on_confirm call, the BAP MUST close the loop by sending a confirm call with the same details as sent in on_confirm

2. 20% of amount was not used. So REFUND of 30 ₹

• This event is a post-order-confirmation state change, where the charging session completes without consuming the amount that was paid for before the confirmation of the order
• In such a scenario, the BPP recalculates the final amount, updates the order and sends an on_update with the new payable amount and breakup, along with an updated payment status as 'PAID'
• The remaining refundable amount is also shown as a refund line item in the breakup like
  • charging services : ₹150
  • CGST @ 5% (taxes) : ₹7.5
  • SGST @ 5% (taxes) : ₹7.5
  • Refund initiated :- ₹30
  • Total payable : ₹135 (150 + 7.5 + 7.5 - 30)
• The BAP can use the payment status change sent via on_update to update its state and show the latest state of the order

3. The charger did not when the prepaid amount was fully consumed, resulting in an overcharge collection

• This event is similar to the previous one, except that now there is an additional payment that needs to be done after the confirmation of the order.
• In this case, the BPP recalculates the payable amount and sends an asynchronous on_update with the new payment breakup along with an updated payment status as 'NOT-PAID' like shown below,
  • Charging services : ₹150
  • CGST @ 5% (taxes) : ₹7.5
  • SGST @ 5% (taxes) : ₹7.5
  • Payment received : -₹165
  • Overcharge amount : ₹45
  • Total payable : ₹45 (150 + 7.5 + 7.5 - 165 + 45)
• However, this time, the BPP also sends the payment link, and/or any other supported payment endpoints as well,
• Upon receiving the on_update, the BAP invokes the respective checkout flow again and enables the user to make the payment
• Upon verifying the payment (or promise of payment), the BPP then calls a second on_update on the BAP to communicate its receipt of payment with an updated payment status as 'PAID'
• The BAP then updates its state from 'Awaiting payment' to its next appropriate state like say, charging completed.

Conclusion

The above solution demonstrate how off-network actions like Payment can be updated and synchronized with the BAP and the BPP via a simple exchange of latest state of the order. It does not require payment history to be transmitted. The BAP and the BPP both update their internal order books by exchanging ALL state changes to the order via independent Beckn API calls.

Alternate solutions

However, it is worth noting that the above solution is just one possible flow. In a different scenario, a BPP could just record the second pending payment and add it as a line item to a subsequent order from the same customer during on_init. Like this,
- Charging services : ₹100
- CGST @ 5% (taxes) : ₹5
- SGST @ 5% (taxes) : ₹5
- Pending overcharge payment : ₹45
- Total payable : ₹155 (100 + 5 + 5 + 45)

It is also possible that the BAP may avoid the second payment flow altogether to maintain a clean user experience and settle the amount to the BPP internally while recovering the payable amount from its user via other methods, or sometimes even absorbing the cost through promotional offers.

Quick tips:

1. The above scenario is a typical flow in on-demand mobility use cases where the actual length of the ride exceeds the estimated length of the ride used for calculating the payment
2. The same solution can be extended to synchronize other actions happening off the network besides payments like external form submissions, providing consent

CC: @bachia @nirmay