What is card authorisation testing?

Card authorisation testing verifies that a card payment request receives the correct approval or decline decision and that the result is handled correctly by connected systems. It covers request data, issuer or processor responses, transaction state changes and error handling across the payment path. Tests use controlled test environments and test card data to exercise valid, declined and failed authorisations without initiating live transactions.

How card authorisation works

When a customer attempts a card purchase, the merchant system sends an authorisation request through its acquirer or payment processor. The request is routed through the relevant card network to the issuer, which returns a decision. The response travels back to the merchant system, where the payment and order status should reflect the outcome.

The issuer's decision can depend on factors such as account status, available funds or credit, card controls and fraud checks. The exact checks and response codes depend on the issuer and payment integration. An approval commonly places a hold against available funds or credit; it does not, by itself, confirm that the transaction has been cleared and settled.

Authorisation testing focuses on this decision and its handling. It may involve application tests, API testing of a payment service, integration tests with a processor simulator, or end-to-end testing across a checkout and order-management system. The appropriate scope depends on which components the team controls and which dependencies can be safely simulated.

What to test

A useful test set covers expected outcomes and the handling around them:

• An eligible test card and valid request produce the expected approval response and payment state.
• A declined response leaves the order unpaid, displays an appropriate message and does not trigger fulfilment.
• Missing, malformed or unsupported request fields produce the documented validation result.
• A processor timeout or unavailable dependency leaves the transaction in a defined state, with safe retry behaviour.
• A repeated request does not create an unintended second authorisation when the integration supports idempotency.
• An approved request followed by a cancellation or reversal updates the payment state correctly when that workflow is in scope.

Assertions should cover more than the HTTP status. Check the response code and transaction identifier where applicable, the stored payment state, customer-facing outcome, order state and any downstream event or notification. For asynchronous integrations, verify that delayed responses and events lead to a consistent final state.

Practical API test example

Suppose a checkout service submits an authorisation request to a payment API. A test can use a provider-approved test card configured to return an approval, then assert the response and resulting application state. A companion negative test can use test data configured for a decline.

Given an unpaid order and an approved test card
When the checkout service submits an authorisation request
Then the API returns the expected approval outcome
And the payment record is authorised
And the order is not marked as settled

For the decline case, assert that the payment record is declined and the order remains unfulfilled. Use the processor's documented test scenarios and response values rather than assuming that a particular card number or code has the same behaviour across providers.

Preconditions and common failure modes

Use a sandbox or other approved test environment, configured credentials and test card data supplied for that environment. Confirm how the integration represents timeouts, declines, retries and asynchronous responses before writing assertions. Production card data should not be copied into test fixtures; protect test credentials and transaction records according to the organisation's data-handling controls.

Failures can arise from incorrect request mapping, environment drift, stale test data, mismatched response-code handling or ambiguous retry rules. A timeout deserves particular attention: the caller may not know whether the processor received the request. Retrying without a defined idempotency or transaction-status check can create duplicate attempts. Test the application's documented recovery behaviour and verify the resulting state in both the payment service and any dependent order system.

Card authorisation testing is distinct from cardholder authentication testing. Authentication establishes that the person attempting the payment has met an identity check; authorisation determines whether the payment request is accepted. A payment flow may include both, and a test plan should cover their integration where relevant.