This action allows transactions to be declined before they are routed to one of
the connections. A custom error_code can be set which is returned on the
transaction API to indicate the reason for the decline.
This action allows transactions to be routed to a subset of connections. A
transaction is 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 is declined.
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. Either the same conditions or potentially different conditions can be used. The optimal routing can be set up using preferred payment instruments and message transformations to optimize payment strategy. The routing rules are configured as a list; each transaction is attempted going down the list. That means that whichever combination of instruments and message types are configured overrides the transaction request sent in, and the rule configuration is taken as leading. If no transformation or default instrument (PAN) is selected, the transaction is processed as received on the API.
Under the following conditions, transactions are retried with the next rule in the routing sequence:
Failures: Attempts that fail due to technical reasons are 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 are 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 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 are routed through it.This enables:
The routing framework allows granular rules to be set up 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.
It is currently possible to choose to route transactions using two instruments, PAN, or Network Token. For routing network tokens, network tokens need to be enabled, and the connection needs to support the submission of network tokens. If either of these is not supported, network tokens are not used, and the rule is skipped. If the payment service doesn’t support the submission of network tokens, it is not configurable. Setting up a PAN rule as a default is advised.
By choosing a message transformation, the presentment of the transaction message towards the payment service can be altered. 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 the business model is inherently not a subscription based model or supportive of any recurring transactions, reprimands can be issued by the card schemes for incorrect flagging of transactions. Sanctions are levied on the acquirer; however, these can be passed through to the merchant.
MIT
By selecting this transformation, transactions are sent to the payment service as a merchant initiated transaction (MIT).Please note that this message transformation should be used with caution. If the business model is inherently not a subscription based model, or supportive of any recurring transactions, then reprimands can be issued by the card schemes for incorrect flagging of transactions.Sanctions are levied on the acquirer; however, these can be passed through to the merchant. If the original transaction is already sent as an MIT, no transformation happens 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 is skipped. For example, for a co-badged Visa card that also supports the Cartes Bancaires scheme,
adding this transformation forces 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 intended to be used.In general, the following rules apply.
A rule is skipped if the intent is set to authorise and the co-badged scheme does not support delayed capture, for example EFTPOS.
A rule is 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 to prevent triggering 3DS again. Note that currently the 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 the vault but the service’s tokens, the token is sent 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.
For merchants who have the account updater enabled, additional logic
applies after a transaction has been declined.When the 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 the old card details are marked as inactive and the payment
method is updated 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.
Amount: This enables filtering based on the amount for the transaction. Each
rule defines a single currency for which it applies. A minimum
amount, maximum amount, or a range for the amount can be specified.
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, {"foo": "bar"} could be passed and a
condition created 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, {"foo": "200.1"} could be passed and a condition created 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
