What is card payment stand-in processing testing?

Card payment stand-in processing testing verifies that card authorisations are handled correctly when the issuer or its authorisation host cannot respond. A stand-in service, often provided by a card network or another authorised processing component, makes a temporary decision using configured rules and the data available to it. Testing checks that this fallback protects transaction processing while applying the issuer's agreed controls and supporting later reconciliation.

What card payment stand-in processing testing covers

The stand-in service may approve or decline eligible transactions on the issuer's behalf. Its decision rules and limits depend on the relevant network, processor and issuer configuration. These can include transaction eligibility, amount thresholds, cumulative exposure limits, card status data and permitted response codes. A transaction that exceeds a limit or falls outside the configured rules may be declined or handled according to another defined outcome.

Testing checks the failure trigger as well as the decision. The issuer connection might time out, return a technical error or become unavailable. A test should confirm that the system recognises the applicable failure condition, routes only eligible requests to stand-in processing and returns a valid response within the required processing flow. It should also verify that normal authorisation resumes when the issuer service recovers.

The scope can include response mapping, stand-in indicators, transaction logging, reversals, duplicate requests and the handling of authorisation records after recovery. It should cover both approved and declined outcomes. An approval must not bypass configured limits or controls, and a decline must be communicated consistently to the requesting processor or merchant channel.

How to test the fallback safely

Use a controlled test environment with issuer connectivity that can be deliberately interrupted or made to time out. Coordinate the scenarios with the processor or network test facility where the stand-in decision is external to the issuer system. Confirm the test configuration, eligible transaction types, thresholds and expected response mapping before execution. Avoid sending live cardholder or payment traffic through a test failure scenario.

Prepare test cards and transaction data that exercise boundary conditions, such as an amount just within a configured limit and one that exceeds it. Include repeated requests, reversals and transactions submitted while the issuer is unavailable. Record the request, the failure condition, the stand-in decision and the returned response. After service recovery, verify that the issuer receives or can reconcile the required transaction information, and that retrying a request does not create an unintended second authorisation.

A test result should be supported by evidence from the relevant components, such as processor logs, issuer records and response messages. Check that timestamps and transaction references allow the same request to be followed across those records. A successful customer-facing response alone does not establish that the stand-in decision, limits or subsequent records were correct.

Practical test example

Assume the test configuration permits stand-in approval for an eligible purchase up to a specified amount. The issuer host is then made unavailable in the test environment.

1. Submit an eligible purchase below the configured limit. Verify that the stand-in service returns the expected approval and that the response is identified and logged as a stand-in decision where the interface supports that information.
2. Submit an otherwise eligible purchase above the limit. Verify the configured outcome, including the response code and any required decline handling.
3. Restore issuer connectivity and check that subsequent requests follow the normal authorisation path. Review the issuer and processor records for consistent transaction references and correct handling of the earlier stand-in decisions.

The test passes when each request follows the configured decision path, the returned result is correctly recorded, and recovery does not lose or duplicate transaction handling. The exact expected outcomes must come from the applicable issuer and processing configuration.