We've reached the end of GSOC. From the mid-term to this point, the API has been through some major changes, most of which have to do with validation and error handling. Particularly, the changes include:
- Providing a systematically for catching validation and gateway errors. Validation errors are thrown as exceptions when no data has been sent to the external gateway yet. Gateway errors are saved directly to the database after they're returned back from the external gateway and can be processed by looking up the database records.
- Updating DummyPayment and PaymentTest to reflect and demonstrate the API changes.
- Minor changes including changing naming convention, improving inheritance structure...
So to summarize the whole project, here are the most notable features of the new Payment API:
This is the biggest part of the project. Over the last 3 months, we have been experimenting with different approaches and finally came up with a stable system to handle various types of payment gateways. The architecture is summarized in this diagram:
What's good about this architecture is that it is loosely coupled and gives developers the flexibility to customize it based on their own needs. Detailed documentation of the architecture can be found in the SilverStripe docs.
2. Yaml configuration:
To achieve the desired flexibility, we've developed a yaml config system that is capable of registering and configuring payment gateways. For example, when developing a new payment gateway integration, the developer can specify which classes he wants to use for model, processor, and gateway:
PaymentFactory: NewGateway: title: 'A new payment gateway' processor: 'PaymentProcessor_MerchantHosted' gateway_classes: live: 'NewGateway' dev: 'NewGateway' test: 'NewGateway' model: 'NewGatewayModel'
That way he does not have to adhere to the default classes provided by the API if they are not suitable for the gateway being developed. By default, every implementation of a new gateway can just use the model class
Payment and the processor classes
PaymentProcessor_GatewayHosted, but it's not compulsary.
3. Unit testing with mock gateway:
This is another good feature that we've included in the API. Basically unit testing is quite difficult when it comes to dealing with external API. To tackle this problem, we've implemented a mock gateway system to be used for testing purpose only. An example can be found in the PayPal Direct Payment's mock gateway. which mocks up the responses based on a template response from the PayPal server. The mock gateway then uses the PayPalDirect API methods to process the dummy responses and return the respective results. That way we can use the mock gateway for effective unit testing.
4. PaymentTest module and DummyPayment:
API is not complete when there's no demonstration to show what it can do. In order to demonstrate the Payment API, we use the PaymentTest module and DummyPayment.
DummyPayment is basically a mock gateway that generates dummy requests and responses and process them using the base API.
PaymentTest is a means for UI testing and used for testing the payment flow. It provides a form for choosing payment methods and processes a test payment. The
PaymentTest module is good for Sandbox testing, i.e. testing with the remote API in a test environment.
There are still a few things to be done in order for the module to be ready for a release. All the works that needs to be done are specified in the GitHub Issues List. Moreover, more payment gateways need to be supported, and that will be done after GSOC. Right now my mentors and I have accomplished the minimum-viable results for GSOC. All the work after GSOC will be our own open-source contributions to SilverStripe.