Testing your card implementation is essential to ensuring the successful rollout of any new card program. While initial testing can be completed in the sandbox environment, it is highly recommended that production testing be performed to ensure that all elements of the card implementation are functioning as expected before launching your program with customers.
Simulation type | Card event message type | Explanation |
---|---|---|
card_event.auth_capture | auth-capture | Notification that a previous authorization has been captured (related holds are released and funds moved as a result of this request). |
card_event.auth_clear_request | auth-clear-request | Request to authorize and capture funds in one message (funds are moved immediately). |
card_event.auth_request | auth-request | Request to authorize spending with card (if approved, this places a hold on funds). Note that this simulation will have any applicable card controls run against the auth request. |
card_event.auth_reversal | auth-reversal | Notification that a previous authorization has been reversed. |
card_event.refund | refund | Refunds a previously completed transaction |
trace_id
for the auth_request
is required. You can retrieve this from either the card_event generated upon receipt of the auth request or the transaction endpoint.
Here it is located via the account transaction endpoint via this request.
hold
generated in response to the auth request is the most recent transaction.
trace_id
has been found, an auth capture request can be created, simulating the verification of the auth request. The trace_id
is supplied as the external_id
for our simulation call. The external_id
links the initial auth request and the subsequent auth capture. The auth capture will release the hold and debit the funds from the account.
mcc
value of the Merchant sub-object in the Card Simulation request body to verify that the specified categories are, in-fact, blocked.
mcc
property of the Merchant sub-object to mimic transactions at merchants in these categories
auth-request
card simulations that fall within and surpass these limitations
auth-request
simulations to trigger the Card Auth Loop Endpointauth-request
card simulations on an unactivated, terminated, and suspended cardauth-request
card simulations with an amount
greater than the available_balance
on the account to simulate non-sufficient funds (NSF)amount
greater than the available_balance
on the accountamount
greater than the available_balance
on the accountauth-request
for a low value (such as $1) and then later submit an auth-capture
for a much higher amount (the total fuel cost). This can lead to overdraft scenarios and is something you should consider if anticipating spend at these types of merchants.