Card Transactions Flow

​

Action: Decline

This action allows you to decline transactions before they are routed to one of your connections.

​

Action: Route to connection

This action allows you to route transactions to a subset of your connections. A transaction will be processed sequentially with the defined outcome connections until it is successful. If a rule is matched and there are no active connections or all connections fail to process the request the transaction will be declined.

​

Retries and cascading

Using the card route configuration framework, transactions can both be retried via the same connection under a different condition, or cascade through to another connection. You can use either the same conditions or potentially route to different conditions. It is up to you to set up the optimal routing using preferred payment instruments and message transformations to optimize for your payment strategy. The routing rules are configured as a list, each transaction will be attempted going down the list. That means that whichever combination of instruments and message types are configured will override the transaction request as you sent in, the rule configuration will be taken as leading. If no transformation or default instrument (PAN) is selected, the transaction will be processed as received on the API.

​

Failures and Retriable declines

Under the following conditions transactions will be retried with the next rule in the routing sequence:

Failures: Attempts that fail due to technical reasons will be automatically retried with the next connection in the sequence. Without any retry the end status of this attempt would be authorization_failed.

Retriable declines: transactions that are declined with retriable decline codes will be automatically retried with the next connections in the sequence. Retriable declines are mapped from generic decline codes of the payment service to a set of retriable decline codes. In essence they pertain to soft declines from the issuer, or technical decline codes from the acquirer or payment service that allow for retries via a different payment service.

​

Instruments and message transformations

The routing framework allows you to set up granular rules by allowing the choice of instrument to be processed with, and how the transaction message is presented to the payment service. The choice of instrument can be combined with the message transformation where available.

Instruments: It is currently possible to choose to route transactions using two instruments, PAN or Network Token. For routing network tokens, you need to have network tokens enabled, and the connection needs to support the submission of network tokens. If either of these is not supported, network tokens will not be used and the rule will be skipped. If the payment service doesn’t support the submission of network tokens it will not be configurable. We advise you to always set up a PAN rule as a default.

Message transformations: By choosing a message transformation you can alter the presentment of the transaction message towards the payment service. It is currently possible to override the transaction as an MIT transaction. Please note that using this message transformation should be used with caution. If your business model is inherently not a subscription based model or supportive of any recurring transactions you can be reprimanded by the card schemes for incorrect flagging of transactions. Sanctions will be levied on the acquirer, however these can be passed through to the merchant.

The framework is built so that it’s easy to add any message transformation type or instrument. In the future we will be expanding this functionality by adding co-badged card routing.

​

Payment method replacement

For merchants who have our account updater enabled, we have some additional logic that applies after a transaction has been declined.

When our account updater has received new details for a card, but the card hasn’t expired yet, then these new details are left inactive and on standby for future use.

If this card is then used at a later point and the card is declined by a connection, then we will mark the old card details as inactive and we will update the payment method with the new card details from the account updater. The transaction is subsequently retried with the new details with the same connection. This retry is applied outside of any retries that are configured as part of Flow.

​

Payment method replacement

For merchants who have our account updater enabled, we have some additional logic that applies after a transaction has been declined.

When our account updater has received new details for a card, but the card hasn’t expired yet, then these new details are left inactive and on standby for future use.

If this card is then used at a later point and the card is declined by a connection, then we will mark the old card details as inactive and we will update the payment method with the new card details from the account updater. The transaction is subsequently retried with the new details with the same connection. This retry is applied outside of any retries that are configured as part of Flow.

​

Action: 3-D Secure

This action allows you to control when 3-D Secure is required for transactions.

​

Conditions

You can add the following conditions:

• Amount: This enables filtering based on the amount for the transaction. Each rule defines a single currency for which it applies. You can specify a minimum amount, maximum amount, or a range for the amount.

• Anti-fraud decision: This enables filtering based on a risk decision received from an anti-fraud provider as an inclusive or exclusive list of decisions. Note that Error (unable to get decision) represents a state where a decision is unobtainable. For example, due to a network timeout or server error.

• Browser language: This enables filtering based on a buyer’s browser language.

• BIN range: This enables filtering on up to the first eight digits of the card, for example: 4242-4545 or 12345678-12345678.

• Card country: This enables filtering based on the country of the card as an inclusive or exclusive list of countries.

• Card scheme: This enables filtering based on the scheme of the card as an inclusive or exclusive list of schemes.

• Card source: This enables filtering based on the input used for the card, for example: Apple Pay, Google Pay, tokenized, or one-off card details.

• Card type: This enables filtering based on the type of the card as an inclusive or exclusive list of types.

• Country: This enables filtering based on the customer’s country as an inclusive or exclusive list of countries.

• Currency: This enables filtering based on the transaction currency as an inclusive or exclusive list of currencies.

• Is subsequent payment: This enables filtering based on the transaction’s is_subsequent_payment flag value, set to either true or false.

• Merchant initiated: This enables filtering based on the transaction’s merchant_initiated flag value, set to either true or false.

• Metadata: This enables filtering based on key/value strings from an object passed to the API. This currently only supports matching/not matching string values. For example you could pass {"foo": "bar"} and create a condition based on the value of the foo key.

• Payment source: This enables filtering based on the transaction payment source as an inclusive or exclusive list of payment sources.

• Product categories: This enables filtering based on the product categories of cart items.

• Product types: This enables filtering based on the product types of cart items.

• SKUs: This enables filtering based on the SKUs of cart items.