Concepts

A credit card payment moves through many steps from the cardholder offering their card as the method of payment all the way to the merchant receiving funds in their bank account. Use the guide below to better understand each phase in card payment.

1. Card Acceptance

The cardholder inputs their card data into a secure form.

In online payment processing, this form is presented on a website or mobile app, asking for the credit card number (sometimes referred to as a Personal Account Number or PAN), the expiry date, and the Card Verification Data (CVD). Moneris provides solutions to integrate with your online website for collecting card data in a secure manner, such as Hosted Tokenization or Moneris Checkout. You can also develop your own solution to collect card data, but doing so requires PCI compliance to ensure the security of the data.

2. Cardholder Authentication

The cardholder proves their identity to their issuing bank.

For services like 3-D Secure, this might involve a seamless experience with the bank using device details from the cardholder’s browser session to confirm identity. It can also involve a more direct prompt for passcodes as a challenge or a text with a temporary code to input in a banking application.

3. Card Authorization

Moneris ensures the card is valid, funds are available, and reserves funds for the merchant.

Either authorization or pre-authorization can occur in this phase depending on the transaction type selected by the merchant.

  • Authorization is used for short-term holds on funds. The final captured amount is the same as the authorized amount. This type is used within a Purchase transaction.

  • Pre-Authorization is used for temporary holds on funds lasting periods between 7 and 31 days. The final captured amount may differ from the temporary hold within variances allowed by each card brand.

    • The issuing bank and the merchant’s business vertical (Merchant Category) can influence the period funds are held

    • Card brands allow businesses to capture held funds for less than the initial hold. This is often used in business for rental agencies taking a “security deposit” for potential fees that may or may not incur.

Until a preauthorization is captured, it remains eligible for cancellation.

4. Capture

Moneris ensures that funds on the card are scheduled for deposit to the merchant’s bank account.

All captured payments accumulate within an open batch, a bundle of transactions

Until the batch is closed, a captured payment is eligible for cancellation. Cancelling a captured payment that used pre-authorization in the previous step does not allow reuse of that pre-authorization; the merchant must restart the payment process again if they wish to charge the card for a different amount.

Merchant accounts using Moneris Gateway products have their batch close automated for 11PM at night. If a merchant wishes to close their batch at a different time that suits their business model, the automation can be adjusted within their account’s Merchant Resource Center.

5. Credential on File

Cardholders may authorize merchants to save payment methods as a stored credential for use in subsequent transactions. However, transactions involving the storage or usage of credentials require merchants to identify the usage within common scenarios and business practices. Correctly identifying stored credentials allows for improved treatment of transactions through the authorization approval process, enhances visibility of transaction risk to Moneris and issuers, and improves the cardholder experience. 

Merchants may choose to securely store credentials on file with Moneris via our API and receive a paymentMethodID in response. Merchants can safely keep these IDs as tokens within their own records and systems without need for certification to expensive Payment Card Industry Data Security Standards (PCI DSS) require for managing a payment credential on file themselves. 

What Counts as a Stored Credential? 

Data only becomes a stored credential on file when a cardholder consents to their card data used by a merchant as part of a customer profile intended for processing future transactions. Merchants only retaining card data temporarily as part of a single payment with multiple API calls are not considered as storing a credential on file. 

Some agreements may include terms on how the stored payment method is intended for use, such as: 

  • A recurring series of payments for a fixed amount per payment on a fixed schedule 

  • A recurring series of payments for a variable amount per payment on a fixed schedule 

  • An installment series for a single purchase with a known total amount processed as component transactions over a specified duration 

Credentials stored under these agreements may only be used for their intended purpose. 

Some agreements may allow the merchant to use the stored payment method for any use scenario. These include: 

  • Any of the series noted above 

  • Unscheduled transactions without pre-agreed fixed amounts, initiated by the merchant 

  • Unscheduled transactions initiated by the cardholder 

Disclosure & Cardholder Consent 

Card brands require that merchants disclose intention to store cardholder data as a credential on file for future use and establish the cardholder’s consent. The agreement must include: 

  

  • A truncated version of the stored credential (last four digits of the card or account number) 

  • How the cardholder will be notified of any changes to the consent agreement 

  • The expiration date of the consent agreement (if applicable) 

  • How the stored credential will be used by the merchant 

Storing & Using Credentials on File 

Payment methods can be created though the POST Create Payment endpoint to temporarily record data as a paymentMethodID. During a Validation or Payment, you may choose to convert the payment method to a permanent credential on file via the storePaymentMethod field. At this time, you must indicate the merchant intentions for the stored payment method: 

  • MERCHANT_INITIATED indicates storing the payment method permanently for all subsequent transaction types, whether cardholder-initiated or merchant-initiated 

  • CARDHOLDER_INITIATED indicates storing the payment method solely for subsequent unscheduled cardholder-initiated transactions only 

  • DO_NOT_STORE will prevent the Moneris API from storing the payment data as a credential for future use 

If either of the options for storing are selected, Moneris mandates the merchant to populate the credentialOnFileInformation object providing details on intended use of the credential; subsequent transactions will track use scenarios as well. Our API Reference for the object and its field covers the possible values individually, but you may wish to consult the tables below for the possible combinations of paymentIndicator and paymentInformation to better understand the business practices where a merchant must track information related to credentials on file. The tables are divided into first transactions, where the payment method is input by the cardholder and stored as a credential on file by the merchant, and subsequent transactions where the credential is used afterward. 


First Transactions for Storing Credentials 

When storing a credential for future use, the merchant must submit the intentions for the credential as the paymentIndicator within the first Validation or Payment. In the response, the merchant receives an issuerID that will act as the link from this first transaction to all subsequent afterward. 

Subsequent Transactions Using Credentials 

When using a stored credential, the merchant must submit the best-fitting scenario below as the paymentIndicator within the subsequent transaction. The value in issuerID in this subsequent transaction must match the one returned in the response of the first transaction prior.