Today at Liones I started working on the integration of a payment service provider (PSP) for a web shop implementation. While I was thinking about the architecture I discovered that it is actually very straightforward and that most of the application flow is reusable in different implementations with other PSPs.

Take a look at the UML diagram below; you will notice that there are actually two flows:

• One synchronous, which guides the user trough the payment screen
• One asynchronous, which notifies when the payment state changed (payment is confirmed or canceled)

Synchronous flow

A said: the synchronous flow guides the user through the confirmation, payment and thank you steps. The following steps are taken:

1. A record is created to track the status of the payment for the order that is being made.
2. The user is redirected to the payment provider page, this can be done using various methods including HTTP GET and HTTP POST. One of the parameters is the ID of the payment record. The other parameters depend on the PSP and might include a message signature, a merchant ID or a redirect URL for example.
3. The user fills in his credit card information, IDEAL information or any other payment information supported by the PSP. Once the user has filled in that info, the PSP processes the payment and redirects the user back to the web shop application, usually with some confirmation information, like: status (failed, in processes) and a transaction ID, in the parameters.
4. The web application stores the transaction ID in the payment record and shows the thank you text to the user.

That is it for the synchronous flow.

Asynchronous flow

The asynchronous flow, often called notification flow, is used to give the web shop status updates about the payments. This asynchronous flow is needed because a payment might take several days or even weeks to complete. For instance: when a user pays by transferring money into a designated bank account he/she usually has two weeks to do so. The asynchronous flow can be initiated by either the PSP or the web shop depending on the specific PSP implementation.

The single purpose of the asynchronous flow is to update the payment identified by either the payment ID (generated by the web shop) or the transaction ID (generated by the PSP). Once a payment status has been updated the asynchronous flow could send a mail to the user to inform him/her that the payment is complete.

Conclusion

Although the implementation specifics vary between PSP, the general flow as described above is pretty consistent for PSPs. I hope you can integrate a PSP with your web shop in the same way, if not please let me now: this pattern needs a revision.