Regarding the use of transaction_id and other ids

[pkapustin]

We had a long discussion regarding the use of transaction_id and other ids (message_id, session_id, order id).
I am trying to summarize some of the outcomes of the discussion.

• The purpose of transaction_id is solely to document that the buyer and the seller have entered an agreement (which happens during the confirm/on_confirm calls). The transaction_id should only be used in confirm/on_confirm. This can be used in case of disputes whether a buyer and a seller actually entered an agreement.
• The purpose of order.id is to identify an order (a booking, ticket, reservation, etc.) in all calls succeeding confirm (status, update, cancel, track, feedback, etc.) The order.id generated by the BPP should be unique (preferably a UUID). The order object may also include provider's internal order id in their chosen format (this isn't guaranteed to be unique).
• The purpose of message_id is to identify messages and map callbacks to the original requests. If a callback is a reply to the original request, their message_id should be the same, otherwise they should be different.
• The purpose of optional session_id is to logically group a sequence of calls between the BAP and the BPP with the purpose of tracing and improving customer experience (for example, a BAP may offer additional services based on the session, etc.)

This gives the following benefits:

1. Better separation between the different ids, with their purpose being clearly defined. This minimizes misunderstandings and errors in the implementations.
2. More natural API implementations that are closer to the domain (business usually refer to order id in the communication after it is created)
3. More type safety in the implementations. Identifying an order by a transaction_id is problematic as not all transactions will be confirmed by the seller.

[venkatramanm]

Id Uniqueness across network may be needed for multiple entities. Like fulfilliment,category,provider, provider_category,order, catalog, item, cancellation/return reason.....

./[domain_name]/[internal_item_id]@[provider_id]@[subscriber_id] or some such scheme should work to make it unique.

@core-wg-admin comment from slack "Good point. We can definitely consider something to uniquely identify items. I quite like the URL scheme used by upi, payto etc. Something like item://id/12577?provider. id=abcd what do you think?"

[venkatramanm]

Currently transaction Id is being used as session id. Init and confirm use the same transactionId . Order created at init is in draft status until confirmed and transaction id is used to identify the order. It is not a problem as the order is not confirmed unless confirm is called on the transaction.

Fmd may not need init . That's fine but in retail, I am using init and confirm being connected by transaction Id. If we need a separate one for payments, we can call payment_transaction_Id that can be used for confirmation.

Order Id is ok to have as the primary key. Post confirm. BPP should be able to identify order by beckn transaction id or order Id. This is enough..

[ravi-prakash-v]

Ideally BPP should be unaware of the BAP session. Seeing as all the API calls are stateless, I am not sure why a session is needed. If needed, you can send the BAP session id in the context.message_id attribute itself.

[ravi-prakash-v]

But transaction_id is definitely not equal to session id. And I do not see why the BPP has to be informed of the flow the BAP is taking. The whole design of beckn-enabled networks is to unbundle experience from service.

[ravi-prakash-v]

order_id is a business level attribute that may change with seller whereas transaction_id is a network level attribute. Currently there is a 1:1 mapping between transaction_id and order_id but tomorrow there could be a 1:n mapping where a BPP confirms a transaction but creates multiple orders internally. Could be for a recurring service, or a bulk subscription each with their own order_ids. So I suggest not tightly coupling transaction_id and order_id and keep them separate. That way we will be more future-proof.

[pkapustin]

Ideally BPP should be unaware of the BAP session

I partly agree, but this is the closest we can get to the concept of a user session for pre-confirm calls. Like, if BPP can see several search calls from the same user, it may tailor the items, offers, etc.?

But transaction_id is definitely not equal to session id.

Agree.

And I do not see why the BPP has to be informed of the flow the BAP is taking.

Not about the flow the BAP is taking, but just about what requests are related to the same user session.

order_id is a business level attribute that may change with seller whereas transaction_id is a network level attribute

Could you clarify the difference between business-level and network-level? Also, what do you mean by "may change with seller"?

tomorrow there could be a 1:n mapping where a BPP confirms a transaction but creates multiple orders internally. Could be for a recurring service, or a bulk subscription each with their own order_ids

These recurring orders would still be normally linked to the top-level order, and that can be returned in on_confirm right? Those recurring order ids will probably be not be visible in the Beckn protocol at all? And if they are, they can always be kept separate from the top-level order id?

[ravi-prakash-v]

In beckn, a transaction is defined as the event where the liability of fulfillment of an order is created on the seller.

Therefore, thetransaction_id must be generated by a BAP when it finally calls confirm. If the BPP returns a confirmed order, then all subsequent calls will refer to this transaction_id. In fact, dispute resolution, transaction ledgers will all use this id as reference for various purposes.

[pkapustin]

@core-wg-admin

So I suggest not tightly coupling transaction_id and order_id and keep them separate. That way we will be more future-proof.

Agree.

In beckn, a transaction is defined as the event where the liability of fulfillment of an order is created on the seller.

Agree.

Therefore, thetransaction_id must be generated by a BAP when it finally calls confirm

Agree.

then all subsequent calls will refer to this transaction_id. In fact, dispute resolution, transaction ledgers will all use this id as reference for various purposes

What I suggest is we clearly separate what transaction_id and order_id are used for. I suggest that order_id should be used for order identification after confirm (as this is what it is by definition). I think it is better to use order_id rather than transaction_id for order identification for several reasons:

• It is just simply to identify orders by order_id
• It better matches the domain (it is very common to do this in business)
• BAP only receives order_id in on_confirm if the transaction is actually confirmed by the BPP, so it is a better and less error-prone way of referring to orders after confirm.

Whether or not transaction_id should be included in post-confirm calls is a different question. Personally, I don't see why it is needed, because if there is a dispute whether a certain order id resulted from an actual agreement, one should always check confirm/on_confirm calls. But I don't have a strong opinion on this, and we can include transaction_id in post-confirm if necessary for any reasons.
However, I don't see why transaction_id should be included in pre-confirm calls.