OPEN QUESTION - Adding Transaction time for a Payment

[PedroDiez]

Question raised by STC on 25/JAN meeting regarding both proposals.

Return transaction time of a payment in response (a timestamp). Need to Open an issue on it to detail and provide a way forward. It can make sense to have it.

[bigludo7]

Thanks One quick clarification. As the POST Payment could not systematically have a successful or synchronous payment processing, the requested timestamp is:

1. to track the creation of the Payment resource or
2. to track when the payment has been successfully performed.

For case 1 this is a technical attribute always present present while in case 2 this is an optional attribute.

I guess we want option 2. but looking for your feedback - we can discuss this in next meeting.

CC: @PedroDiez @alabajnaid

[PedroDiez]

I guess the same, the comment is raised for option 2, to have tracking when the payment has successfully accomplished.

Let's talk in the meeting

[bigludo7]

Proposal after February 1st meeting We could add 2 attributes. These 2 attributes are optional and are valued by the server side:

• paymentCreationDate: Date when the payment is created in server DB. This is a technically information
• paymentDate: Date when the payment is effectively performed. This is a business information.

(attribute name is subject to your suggestion).

[PedroDiez]

To me makes sense @bigludo7.

To include in a higher version. With this notation:

• payment_creation_date
• payment_date

Also would make sense to include payment_date in the notification body (when payment notification is generated about its confirmation)

[PedroDiez]

NOTE: As per guidelines, https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/API-design-guidelines.md

input/output params will be snake_case, so for a v1 we need to check in both proposals we are compliance with it.

https://github.com/camaraproject/WorkingGroups/blob/main/Commonalities/documentation/API-design-guidelines.md#42-inputoutput-resource-definition

_These considerations are below:

• API input and output business data will follow the snakecase notation.

[bigludo7]

I have tracked the snake_case in another issue. As we have a lot of api not aligned (Qod, SimSwap) I'm more and more uncomfortable with the snake_case...but that another discussion.

Meanwhile, proposal for date is there: https://github.com/camaraproject/CarrierBillingCheckOut/pull/60

Let review this and once agree I will update the documentation.

[PedroDiez]

Set to closed as covered in PRs: https://github.com/camaraproject/CarrierBillingCheckOut/pull/60 and https://github.com/camaraproject/CarrierBillingCheckOut/pull/64