Merchant integrations that both receive and payout money can be written with the Client Extension.

Building a Custom Money In/Out Merchant Integration

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.

github.com

Implement Rudimentary EWallet with MoneyOut and SinglePayMoneyIn by ds-vinny · Pull Request #10 · DS-Partners/AcmeClientExtension

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.

Key Take-Aways From This Example

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.