Credit Card: Payment Flow

In MENU platform, credit cards represent a distinct payment method type. As with all payment method types, availability of credit card payments is specified on Brand and Venue level. Where all credit card types are listed along with a definition of one or more credit card payment processor instances. MENU 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 registering, etc.

MENU platform payment processor types that implement 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 MENU customers can add multiple payment methods to their account. MENU platform is PCI compliant MENU is PCI-compliant on the level DSS SAQ-A for more information regarding this please check the following link. Depending on the payment processor and application type, credit card data is entered through a specialized interface like encrypted fields, hosted fields or hosted page that is displayed in an iFrame or in a web view. Once the card data is collected and successfully submitted, payment processor returns a token, a non-sensitive credit card identifier, which is stored in the database and used for subsequent ordering and payments. Since customer can have multiple payment methods related to his account, there should always be only one marked as 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 application that rely on iFrame for displaying 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 to that method instances will be removed as well. In case of credit cards 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 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. For fast orders (i.e. Dine-In, Quick Service, Pick & Pay, Take-Out, Delivery ), the order total amount should always be authorized first, and only after the order is successfully sent to POS/Printer the amount is submitted for settlement. On the other hand, delayed order payments (Take-out, Delivery) should settle the order total amount right after the order is created and before sending to POS/Printer. The responsibility for handling ordering context and applying correct authorized/settled flow relies on the payment service, not on payment processor. Credit card payment processor implementation just needs to 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.

Direct Payment Flow

This flow is based on a previously registered payment method and does not require customer to enter any credit card details. After successful ordering, used payment method becomes 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), which makes this flow 3DS compatible. For more information regarding this, please check the following article