Supporting Mastercard and Visa Transaction Frameworks
A payment plugin can be built to support the mandates of:
-
Mastercard Credential-on-File Transaction Framework
-
Visa Stored Credential Transaction Framework
-
Visa Merchant Initiated Transaction Framework
For this purpose, Payment Plugin SDK provides:
-
The capability to determine the Cardholder Initial Transaction ID (TID):
-
For new payment methods, a payment plugin can be built to return the TID in the Callback
ADD_NEW_METHOD
parameter together with other relevant payment method data. The data is saved encrypted to the Billing database. When a merchant-initiated recurring payment transaction (MIT) or a cardholder-initiated payment transaction (CIT) request is sent, the TID together with other relevant payment method data is returned to the plugin by thepayment_method
parameter (see Auth, Capture, and Sell methods). -
For existing payment methods, use this solution to determine the TID.
-
-
The capability to determine whether it is a cardholder-initiated transaction (CIT) or a merchant-initiated transaction (MIT). This capability is ensured by the
transaction_initiator
parameter provided in a few methods (for example, the Sell method).The table below outlines the CIT and MIT definition conditions:
Transaction description Transaction type A customer pays an order through their panel. CIT A reseller pays an order through their panel. CIT A provider pays a reseller's order through the reseller’s classic panel on behalf of the reseller. CIT A reseller pays a subreseller's order through the subreseller’s classic panel on behalf of the subreseller. CIT A provider pays a reseller's order through the PCP. MIT A reseller pays a subreseller's order through the RCP. MIT A provider or reseller pays a customer's order through UX1 on behalf of the customer. MIT A provider or reseller pays a customer's order through their panel (PCP or RCP). MIT BSS automatically processes customer recurring or renewal orders. MIT Payments for automatic balance top-up. MIT -
The capability to determine whether it is a recurring or an unscheduled payment. This capability is ensured by the
transaction_category
parameter provided in a few methods (for example, the Sell method).