Merchant integrations that both receive and payout money can be written with the Client Extension.
Refer to the Pull Request below to learn how to implement a Custom Money In and Money Out Merchant to support an E-Wallet Integration.
The provided example uses two Associate Custom Fields to generate and save a PayerID and track the balance of the E-Wallet instead of actually integrating with a third-party merchant. Commission Payouts increase the balance and any balance can be used to pay for orders. This is accomplished by implementing a child class of the CommissionMerchant and SinglePaymentMoneyInMerchant classes
This code example should only be used to understand how to write an integration with a third-party Merchant. All third-party integrations should be rigorously tested to ensure that there are no defects or miscalculations as they could be very costly.
This example shows the following methods implemented:
With the CommissionMerchant Class:
- The PayCommissions() Method - Required For All Money Out Merchant Integrations
- The ProvisionAccount() Method - Optional method that can be implemented to create and save account information from a third-party system. This may not need to be implemented as some merchants just accept a Unique ID and create an account. With those types of merchants the AssociateID is often used as the Unique Identifier
With the SinglePaymentMoneyInMerchant Class:
- The ChargePayment() Method - Required For All Single Payment Money In Merchant Integrations
- The RefundPayment() Method - Required For All Single Payment Money In Merchant Integrations
- The GetNewPayerId() Method - Optional method that is invoked during checkout flows if Directscale does not have a PayorID saved for the Active Merchant. Not all merchants associate cards to a payor in their system. - NOTE: If a PayorID is not assigned to the associate then the AssociateID will be used instead.
Implementing the SinglePaymentMoneyInMerchant Class
The GetSavePaymentFrame() Method is not implemented unlike the SavedPaymentMoneyInMerchant class implemented in the Custom Money In Merchant article. This is a key difference between the two classes. The SinglePaymentMoneyInMerchant class will only ever show one payment option and does not require the GetSavePaymentFrame() method to be implemented to show a modal for adding other payment methods.
Updated over 1 year ago