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.

While thinking about those requirements I quickly thought of a concept I saw in Python: Try to call find a callable method, otherwise do the default action. In Python you can use ‘getattr(…)’ to get a possible method of a class and with ‘callable(…)’ you can check if the method is actually a method.

You get something like this on your dispatcher object:

def Dispatch(self, methodName, arguments=None)
   method = getattr(self, methodName, None)
   if callable( method ): method( arguments )

I implemented this extensible architecture in exactly the same way. It was fairly easy to do, painless and it is extensible.

Learning multiple programming languages/concepts pay off!

In this post I am going to talk about 1 architectural pattern which can extend the lifetime of a framework significantly. That pattern is the ‘Onion Architecture’.

The ‘Onion Architecture’ is a pattern originally composed by ‘Jeffrey Palermo‘ and it basically says: put the conceptual model and services in the inner most layer and provide the implementation for the conceptual model and services in the outer layers together with the user interface, data access layer and other implementation details which are subject to change.
The further away from the core a layer is, the more likely it is to change and the easier to change.

A layer in the ‘Onion Architecture’ can interact to any layer below it, including the core. However, it can’t interact to any layer above it. This guarantees that more outer layers can be changed without the need to change an inner layer.

One important detail is that a layer isn’t the same as one component. Each layer can contain multiple components, like the image below demonstrates:

Thanks to Jeffrey Palermo for this image

In short, the ‘Onion Architecture’ allows you to:

• Effectively and logically separate concept from implementation.
• Create a dynamic and future proof architecture.
• Replace outdated or ‘rotten’ layers.
• Introduce new components to layers without changing the inner layers

That is it for now; I hope this post gives you a better insight in how to prepare your architecture for change and extendibility. If you have any question please feel free to ask them!

Sources

• http://jeffreypalermo.com/blog/the-onion-architecture-part-1/
• http://jeffreypalermo.com/blog/the-onion-architecture-part-2/
• http://jeffreypalermo.com/blog/the-onion-architecture-part-3/