Callback mechanism: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
{{PageTitle|title=Payment callback mechanism (aka. IPN)}} | {{PageTitle|title=Payment callback mechanism (aka. IPN)}} | ||
Whenever a given payment's state changes, it is expected that the caller system and the Barion database are synchronized. This is accomplished by implementing the '''callback mechanism''' (referred to as "Instant Payment Notification" or "IPN" in some terminology) between the two systems. | Whenever a given payment's state changes, it is expected that the caller system and the Barion database are synchronized. This is accomplished by implementing the '''callback mechanism''' (referred to as ''"Instant Payment Notification"'' or ''"IPN"'' in some terminology) between the two systems. | ||
== The callback process == | == The callback process == |
Revision as of 09:35, 6 February 2017
Payment callback mechanism (aka. IPN)
Whenever a given payment's state changes, it is expected that the caller system and the Barion database are synchronized. This is accomplished by implementing the callback mechanism (referred to as "Instant Payment Notification" or "IPN" in some terminology) between the two systems.
The callback process
The event flow of the implemented callback mechanism is simple:
- The payment gets completed, cancelled or expired.
- The Barion system sends an HTTP POST request to the merchant's system with the payment's unique identifier, indicating that something has just happened, so the merchant's system should check the payment now.
- The merchant's system sends a request to the /v2/Payment/GetPaymentState API endpoint with its POSKey and the received payment identifier.
- Based on the response received, the merchant's system can determine what processing tasks should take place.
Why you should use it
When a Barion Smart Gateway payment process takes place between the two systems, neither of them can rely purely on explicit user interaction to process things. In such situations, the Barion system must inform the merchant's system that the payment has changed in some way, without involving the user.
Here are some examples:
- the payment is completed, but the user closed their browser or lose network connection, preventing them from returning to the webshop or application that redirected them to the Barion Smart Gateway
- the user explicitly cancels the payment, but closes their browser instead of navigating back to the merchant
- the payment is never completed and expires because of the time window limit
Implementing callback handling will save you time and pain tracking such "lost" payments. It also eases the troubleshooting with your customers, since you will always have valid data on your side.
What NOT to do
Never long-poll the /v2/Payment/GetPaymentState API endpoint and wait for the payment status to suddenly change! If you use a high interval between requests, user experience will deteriorate significantly. If you use a small interval, your requests will get throttled.
If you are having difficulties implementing the proper callback flow, consult our developer support!