Storing a Payment Method (Tokenization)

With Tokenization, merchants can securely capture payment methods during transactions. This allows for convenient charging of customer cards later, whether for one-time payments or enrolling the customer in a recurring subscription.

• Merchants can save a customer’s payment method without a charge.
• Reduction in customer intervention every time merchants need to process a payment.
• Reusability of payment methods for online / in-person transactions and refunds.
• Frictionless customer experience, leading to higher customer retention.

When you first store a customer’s card details after approval and a successful transaction, Stax records the transaction’s details.

On future transactions, the stored card details and previous transaction details are referenced to decrease the chance of a decline.

In addition, the reason the card is stored is also provided (for regular payments, installment plans, recurring, or other reasons).

You must specify who initiated storing the card details (merchant or customer). Stax, by default, sends this data based on where the transaction occurred. For example, if the transaction happened on the customer portal, the type would be set to CIT or customer-initiated transaction.

Note: If you have your own scheduler or wish to override these settings, See our API for the correct metadata to send.

Credential on File Types

Scheduled: This is for regular payments, like subscriptions or payments split into several parts over time.
Unscheduled: For payments that don’t have a fixed schedule.

Types of Future Transactions (MIT or CIT):

MIT (Merchant Initiated Transaction): This is when the merchant starts a transaction without the customer directly involved, like a subscription renewal or recurring transaction.
CIT (Customer Initiated Transaction): This is when the customer is actively involved in the transaction, like buying something from your merchant website.