​
Action: Decline

This action allows you to decline transactions before they are routed to one of your connections. A custom error_code can be set which will be returned on the transaction API to indicate the reason for the decline.

​
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 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 you sent in, and 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.

​
Split Routing

Split routing allows distributing transactions across multiple routing rules based on percentage allocation. When a split routing condition is added to a routing rule, it defines the probability (as a percentage) of that rule being triggered for transactions that already meet the rule’s other conditions. For example, if a rule has a split routing condition of 30%, approximately 30% of the transactions that satisfy all other conditions of that rule will be routed through it. This enables:
  • A/B testing of different routing configurations
  • Load balancing between multiple connectors
  • Gradual deployment of new routing rules

​
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.
MIT
By selecting this transformation your transactions will be sent to the payment service as a merchant initiated transaction (MIT). Please note that 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, then 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 you, the merchant. If the original transaction is already sent as an MIT no transformation will happen as the original transaction is already an MIT transaction.
Co-badged routing
This transformation forces the processing of a transaction to use the first additional scheme (co-badged scheme) of the card instead of its main scheme. If the card doesn’t have any co-badged schemes, this transformation will be skipped. For example, for co-badged Visa card that also supports the Cartes Bancaires scheme, adding this transformation will force the transaction to be processed as Cartes Bancaires. It is important to make sure that co-badged acquiring routes are configured on the payment service you intend to use. In general, the following rules apply.
  • A rule will be skipped if the intent is set to authorise and the co-badged scheme does not support delayed capture, for example EFTPOS.
  • A rule will be skipped if the card only supports one known scheme.
  • When using 3DS, if the scheme used for the transaction is different to the scheme used to authenticate 3DS, then the 3DS payload is dropped and not used to process the transaction. This is done in order to prevent triggering 3DS again. Note that currently our 3DS integration does not support most co-badged card schemes.
  • Network tokens are currently not supported in combination with co-badged schemed.
  • For any payment services that do not rely on our vault but the service’s tokens, we will send the token in combination with the additional scheme
  • For subsequent transactions that use a network transaction id (scheme reference) to link it to the initial transaction, if the scheme to be used doesn’t match the scheme of the ID, then the attempt is skipped, and the next strategy in the rule is attempted.

​
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 issuer name: This enables filtering based on the issuer name of the card, for example: “Bank of America NA” or “HSBC Continental Europe”. It can be filtered by a part of the name.
  • Card product name: This enables filtering based on the card product name, for example: “Visa Platinum” or “MasterCard Black”. It can be filtered by a part of the name.
  • 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.
  • Gift card BIN range: This enables filtering on up to the first nine digits of a gift card, for example: 4242-4545 or 123456789-123456789.
  • Has gift cards: This enables filtering based on whether gift cards were used in the transaction.
  • 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.
  • Metadata (Numeric): This enables filtering based on key/value numeric strings from an object passed to the API. It only supports numeric comparisons like less than, equal to, greater than, greater than or equal to and less than or equal to. For example you could pass {"foo": "200.1"} and create a condition based condition based on the numeric value 200.1 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.
  • Split routing: This enables filtering based on set probability (percentage), for example, setting 30 would evaluate to true for approximately 30% of requests.
Rule Validation
  • You may only have one amount or currency condition per rule
  • You may only have one browser language condition per rule
  • You may only have one BIN range condition per rule
  • You may only have one card country condition per rule
  • You may only have one card scheme condition per rule
  • You may only have one card source condition per rule
  • You may only have one card type condition per rule
  • You may only have one country condition per rule
  • You may only have one currency condition per rule
  • You may only have one gift card BIN range condition per rule
  • You may only have one has gift cards condition per rule
  • You may only have one is subsequent payment condition per rule
  • You may only have one merchant initiated condition per rule
  • You may only have one payment source condition per rule
  • You may only have one product categories condition per rule
  • You may only have one product types condition per rule
  • You may only have one SKUs condition per rule
  • You may only have one Split Routing condition per rule