System Status
Guides
BR-DGE PortalSupport

CLW - Troubleshooting for Smart Routing

How to work out why a rule or fragment has failed to behave as expected.

TOPIC UNDER CONSTRUCTION -more likely to need it when merchants can self service and actually read their own logs!


We endeavour to give you enough logging/reporting functionality to enable you to understand the reason behind any given card being blocked, and for BR-DGE support functions to quickly understand and diagnose issues stemming from rule configurations.

Accessing logging info - HOW? Merchants can't access any logging just now!



How to find things in the logs

When logging transactions, I want entries to be searchable and parsable, so I can find and aggregate that data for end of day reporting and data tables.

When logging blocked rule outputs (see both req 19, 22 and req 23) we must include a clear, searchable indicator of the intent of that logging entry, with any associated data in JSON friendly format. e.g. {"blocked_card_detail": { "rule_id":23, "rule_name":"Block corporate cards"}}


Blocking Rules

If set up to block, transactions should be blocked regardless of entry point into the product - API, (P1) HPP, WebSDK or cashier. (P2) does that mean that block is ignored for 23rd June if transactions start as HPP, WebSDK or cashier?

Transactions that have triggered a blocked rule should not failover and try via a different PSP.

When a transaction triggers a blocked rule, we should return an appropriate HTTP response, and a response code that specifically indicates the transaction was blocked due to routing rules - add 4805 back into the response code doc on the 23rd June!

When I query a transaction that has been blocked, I want an identifier of the specific rule causing that transaction to be blocked to be returned.

DIAGNOSIS

When I am looking at my transaction history in the portal, I want to be able to tell which transactions were blocked due to routing, So I can clearly distinguish between blocked and rejected transactions

Transactions on the portal must display a status of ‘Blocked’ and an identifier of the specific rule causing that transaction to be blocked for transactions blocked due to routing rules.

The response code within the portal should reflect the fact that the transactions was blocked

Reports generated from the portal must display a status of ‘Blocked’ for transactions blocked due to routing rules

When A transaction is blocked by a routing rule I want to understand which specific rule caused that transaction to be blocked So I can determine why a card was blocked and use it to refine my rule setup and aid investigation.

When a rule is triggered for any output fragment, we must include a unique identifier and the name of that rule in the logging for that transaction.

We need to log the fact that the rule has been triggered and some identifier to point to the specific rule. This is so that merchants can understand why a given transaction was blocked, and for analysis as to which rules are blocking many transactions. This will be used for issue investigation and for report generation.


Bin metadata troubleshooting

When BIN metadata is being evaluated for an input fragment and no data is available for a needed field, I want this to be clearly logged, So I can search logs and determine if gaps in our third party BIN data is resulting in transactions passing input checks where they should not.

When BIN lookup is performed and there is missing data (either for a field requested in an input fragment, or for the BIN as a whole) the following information should be logged;

  • BIN - The BIN number used for that lookup
  • Missing Field - The field which was targeted for the lookup
  • Payment ID - A unique ID that can be used to identify and trace this transaction
  • Timestamp - the UTC time the lookup was made

A failed lookup should be logged whether the rule output routed or blocked.

In the case of missing BIN data, the transaction should continue to process as normal, i.e. the rule will fail to match and evaluation should move onto the next rule.


Logging of changes to rules and fragments

When a user changes the routing rule config within the portal, I want a record of that change to be logged, So that support can easily find where routing rule changes are the cause of production issues.

When a user saves a new rule or changes to an existing rule, we must log the following information;

  • Timestamp - UTC time the rule change was made
  • User making the change (portal login email)
  • Rule impacted (Unique ID and name)
  • The rule config before the change (JSON)
  • The rule config after the change (JSON)

It’s possible that users can create rules leading to problems in production as we allow a lot of freedom in rule config. The intention of this is so that support can quickly identify where this is the case, and see detail of the old rule to revert the changes where needed.


Querying logs using the API

When querying standalone routing via API for a transaction which triggers a blocking rule I want the returned PSP ordering to return ‘Block’ So I can route transactions outside of BR-DGE while respecting my full rule setup.

When a blocked rule exists in a merchants rule setup, querying the /standalone-routing-api/v1/payment-routesendpoint should return an entry with ‘Blocked’ within the list.

If a transaction matches a "Blocked" rule, no subsequent valid PSPs from lower-priority rules should be returned in the list.

For example, given rule setup

  1. Route all to PSP1
  2. Block all
  3. Route all to PSP2

querying the payment-routes endpoint should return

PSP1

Block

PSP 2 should not be returned, as it is an invalid route due to the block.