Credit Card: Payment Flow

In the PAR Ordering platform, credit cards represent a distinct payment method type. As with all payment method types, availability of credit card payments is specified at the Brand and Venue level. All credit card types are listed along with a definition of one or more credit card payment processor instances. PAR Ordering platform supports the following credit card types:

• VISA
• MasterCard
• American Express
• Maestro
• JCB

In order to be able to process credit card payments, each credit card payment processor instance needs to implement an interface for the following actions:

• Credit Card Registration
• Credit Card Deletion
• Transaction Authorization
• Transaction Settling
• Transaction Voiding
• Transaction Refunding

Optionally, payment processor instances can support other actions like fetching and searching transactions, customer registration, etc.

PAR Ordering platform payment processor types that implement the credit card payment interface are:

• Saferpay
• Toast
• Adyen
• FAC
• Transbank
• FirstData
• Cybersource
• Paymaya
• Paystack

The payment methods (credit card types) are configurable per payment processor. Not every payment processor supports the same payment methods. In general, all payment processors support at least Mastercard and VISA.

Credit Card Registration

Registered PAR Ordering customers can add multiple payment methods to their account. PAR Ordering platform is PCI-compliant. PAR Ordering is PCI-compliant at level DSS SAQ-A. Depending on the payment processor and application type, credit card data is entered through a specialized interface like encrypted fields, hosted fields, or a hosted page that is displayed in an iFrame or in a web view. Once the card data is collected and successfully submitted, the payment processor returns a token, a non-sensitive credit card identifier, which is stored in the database and used for subsequent ordering and payments. A customer can have multiple payment methods saved to their account. Only one can be marked as the default.

In case there are multiple credit card processors available for the Brand and the active application, credit cards should be registered for each payment processor. Depending on how multiple card registration is handled, there are two card registration flows: Direct and Proxy.

Direct Flow

Client application submits credit card data directly to each payment processor registration endpoint independently. (Flow applied to mobile apps).

Proxy Flow

Flow specific to client applications that rely on an iframe for displaying a credit card form, like web apps. Instead of displaying a card form for each payment processor, a payment proxy service is used to register the credit card temporarily and then forwards card data to each of the credit card payment processors.

Credit Card Deletion

Customers can remove the payment method instances previously added to their account. When a payment method is removed, all related payment processor-specific instances for that method will be removed as well. In case of credit card payment processor, this must include deletion of all the credit card data from the payment processor account.

Transaction Authorization and Settling

Payments are part of the order creation process that is initiated by a request. Payments are always performed before an order is sent to POS/Printer integration, but the exact authorized/settled sequence depends on the ordering context, i.e., order type and order pickup time.

Payments are processed as part of the order creation flow. The authorization and settlement sequence depends on the order type and pickup time:

• Fast orders (Dine-In, Quick Service, Pick & Pay, Take-Out, Delivery): The order total is authorized first. Once the order is successfully sent to the POS or printer, the amount is submitted for settlement.
• Delayed orders (Take-Out, Delivery with a scheduled pickup time): The order total settles immediately after the order is created, before the order is sent to the POS or printer.
• Catering orders (Catering Delivery, Catering Pickup): When pre-authorization is enabled, PAR Ordering places a hold on the customer's card for the full order amount at checkout. The card is not charged at this point. The held amount is captured, and the customer is charged when the order is injected into the POS at the configured payment processing time. See Catering Orders for more information.

The payment service is responsible for determining the correct authorization and settlement flow based on order context. Payment processor implementations must support both transaction authorization and settlement.

Since ordering is available to both registered and guest customers, there are two main payment flows based on whether a previously registered credit card exists or not – Direct and Init payment flow.

Catering Order Pre-Authorization

PAR Ordering supports pre-authorization for catering orders. Pre-authorization is a two-step payment process:

1. Authorization (at checkout): PAR Ordering confirms the customer's card is valid and has sufficient funds. The card is not charged at this point. A hold is placed for the full order amount.
2. Settlement (at order injection): The held amount is captured, and the customer's card is charged when the order is sent to the POS at the configured payment processing time.

This payment flow applies to Catering Delivery and Catering Pickup order types when pre-authorization is enabled for the brand.

Direct Payment Flow

This flow is based on a previously registered payment method and does not require the customer to enter any credit card details. After successful ordering, the used payment method becomes the default one for further payments.

Payment transactions created through this flow are treated as merchant-initiated (MIT).

Init Payment Flow

This flow does not require a previously registered payment method, which makes guest payments possible, but it can be applied to registered payment methods too.

Payment transactions created through this flow are treated as client-initiated (CIT), making it 3DS-compatible.