The Architecture
Last updated
Last updated
The code snippets presented below are only for demonstration purposes (pseudo code). Their goal is to illustrate the general approach to various tasks. To see real life examples please follow the links provided when appropriate. In general, you have to create a , implement in order to know what to do with such request. And use gateway that implements . This is where things get processed. This interface forces us to specify route to possible actions and can execute the request. So, gateway is the place where a request and an action meet together.
Note: If you'd like to see real world examples we have provided you with a sandbox: , .
That's the big picture. Now let's talk about the details:
An action does not want to do all the job alone, so it delegates some responsibilities to other actions. In order to achieve this the action must be a gateway aware action. Only then, it can create a sub request and pass it to the gateway.
Above we see an action which throws a reply. The reply is about redirecting a user to another url. Next code example demonstrate how you catch and process it.
The gateway API has different versions? Or, a gateway provide official sdk? We already thought about these problems and you know what?
Let's say gateway have different versions: first and second. And in the FooAction
we want to use first api and BarAction
second one. To solve this problem we have to implement API aware action to the actions. When such api aware action is added to a gateway it tries to set an API, one by one, to the action until the action accepts one.
As a result of the architecture described above we end up with a well decoupled, easy to extend and reusable library. For example, you can add your domain specific actions or a logger extension. Thanks to its flexibility any task could be achieved.
Payum is an MIT-licensed open source project with its ongoing development made possible entirely by the support of community and our customers. If you'd like to join them, please consider:
Link: See a real world example: .
Link: See paypal .
What about redirects or a credit card form? Some gateways, like Paypal ExpressCheckout for instance, require authorization on their side. Payum can handle such cases and for that we use something called . It is a special object which extends an exception hence could be thrown. You can throw a http redirect reply for example at any time and catch it at a top level.
Link: See real world example: .
Good status handling is very important. Statuses must not be hard coded and should be easy to reuse, hence we use the to handle this. The is provided by default by our library, however you are free to use your own and you can do so by implementing the status interface.
Link: The status logic could be a bit complicated or pretty simple as .
There must be a way to extend the gateway with custom logic. to the rescue. Let's look at the example below. Imagine you want to check permissions before a user can capture the payment:
Link: The is a built-in extension.
Before you are redirected to the gateway side, you may want to store data somewhere, right? We take care of that too. This is handled by and its for gateway. The extension can solve two tasks. First it can save a model after the request is processed. Second, it can find a model by its id before the request is processed. Currently and (use it for tests only!) storages are supported.
Link: See authorize.net .
Next .