Closed bigludo7 closed 1 year ago
I would like to understand the securization method indicated. I am going to upload today Notifications Model in Checkout proposal as well. And would like to know about that securization approach
This is a good point to be discussed. For now I've just followed what have been defined for the QoD API. I guess the pattern should be the same for all API and probably approved in Commonalities.
The idea is:
If API consumer requests to get notification from Carrier Billing server, it has to provide to the Carrier Billing server:
Once Carrier Billing server has to send a notification, it has to send a
`curl -X POST "https://{**notificationUri**}/notifications"
-H "Authorization: Bearer {notificationAuthToken}"
-H "Cache-Control: no-cache"
-H 'accept: application/json'
-H 'Content-Type: application/json'
-d '{ "paymentId": "string",
"action": "prepare_payment",
"status": "succeeded",
"description": "string"
}`
Understood Explanation Ludovic
What do you think @bigludo7 about this issue. Think we can set closed so far, until notifications track discussion is being carried over Commonalities
Hello @PedroDiez Yes we can close it. Meanwhile it is already implemented in the Payment swagger version so we will not forget it.
ok, I close it @bigludo7, thanks for feedback
Point discussed during Jan 18th call. We propose to add a notificationAuthToken attribute in the POST Request. If the Carrier Billing client wishes to get notification for payment status update, Client provided a notification uri. Additionally this attribute provided the token to be used by the Carrier Billing server to POST the notification on the listener side.
We aligned this pattern with QoD API.
Outcome of the discussion: