<logger name="com.broadleafcommerce.payment.service.gateway"><level value="TRACE"/></logger> <logger name="com.broadleafcommerce.vendor"><level value="TRACE"/></logger>
Before you begin, it is recommended that you fully understand how gateways works before attempting to implement any of the BLC interfaces. Please make sure to read Understanding Payment Gateways first to aid in this process.
We’ll go over some of the conventions to create consistency across all Payment Modules.
All implementations of the Payment Gateway Common interfaces will be under
All gateway specific services and constants will be under
All gateway specific web components such as Spring MVC Controllers and Thymeleaf Processors will go under
Some gateways don’t publish their Java SDK on Maven Central, so you may need to install it locally and in your documentation note that their is a dependency on their JAR for compilation. If this is the case, please make note of that and where to find that dependency in your documentation.
In a lot of cases, you may notice that a lot of the transaction methods share common code to create a request that then calls an external API or SDK and parses the response. If this is the case, you may wish to create a parent class that all these extend to unify this boiler plate code.
It’s also important to extend AbstractExternalPaymentGatewayCall if your service makes an SDK or external API call. This allows anyone using the framework to configure the ServiceMonitor AOP hooks and detect any outages to provide (email/logging) feedback when necessary. You can look at the JavaDocs on that class for further examples and documentation.
It’s often very helpful and in some cases required to capture the entire response back from a gateway.
Make sure to serialize all the information coming back from the gateway in the
You may wish to use a
PaymentGatewayWebResponsePrintService to translate an
HttpServletRequest into a
Here are some steps to follow to help get you started developing your own module.
Extend and implement the PaymentGatewayConfiguration. Every module should provide a configuration bean that provides information about what it can and cannot handle as well as any specific configuration parameters it needs.
Implement the PaymentGatewayConfigurationService. Every module should provide an implementation of this service that will define all the Payment Gateway Interfaces that this module supports.
Implement the PaymentGatewayTransactionService to handle any
Implement the PaymentGatewayRollbackService to handle error scenarios. This API will be called in the event an error gets thrown in the Checkout Workflow after a payment has been confirmed. That means the payment has already been captured or authorized however something else in the workflow has caused an exception to occur which therefore needs to rollback any payments that have already been processed.
If it is a Hosted Solution:
Implement the PaymentGatewayHostedService
If it is a Transparent Redirect/Silent Post Solution:
Implement the PaymentGatewayTransparentRedirectService