Note: An example of the
card_token
(recurring token), which you can receive via the
check order status
API
/
order status
Webhook
notification after a
successful
/
declined
payment.
The user tries to complete a payment directly, bypassing any pre-approval or authorization steps. This means the funds are transferred immediately without holding or reserving them first.
Test logic:
Create an order in the
processing
status.
Attempt to execute a payment.
Validate if the order transitions to the
declined
status (transaction
pay
in status
fail
).
The user tries to place a temporary hold on a specific amount of funds on their card. This authorization ensures the amount is available but not immediately transferred, allowing for final confirmation before completing the transaction.
Test logic:
Create an order in the
processing
status.
Attempt to execute an authorization.
Validate if the order transitions to the
auth_failed
status (transaction
auth
in status
fail
).
The merchant seeks to finalize the transaction by capturing the funds that were previously put on hold during the authorization process. This completes the payment and transfers the authorized amount from the customer's account to the merchant's account.
Test logic:
Make successful authorization request, placing the order in status
auth_ok
(transaction auth in status
success
).
Attempt to execute a settlement (settle transaction is in status
created
).
Validate if the settle transaction transitions to the
fail
status. Order in status
auth_ok
; otherwise, it should transition to
settle_ok
.
The merchant initiates a void transaction to cancel the funds that were previously authorized, effectively releasing the hold on the customer's account without completing the charge.
Test logic:
Create an order in the
auth_ok
status (transaction auth in status
success
).
Execute a void operation on the authorized funds (void transaction is initially in the
created
status).
Validate if the void transaction transitions to the
fail
status. If it does, confirm the order remains in
auth_ok
status; otherwise, it should transition to
void_ok
.
The user initiates a process to establish a recurring payment schedule, allowing the merchant to automatically charge their card at specified intervals for ongoing services or subscriptions.
Test logic:
Execute the first payment using auth and successfully authorize it; upon successful authorization, obtain a token (order in
auth_ok
status, and transaction auth in
success
status).
Use the token to execute a recurring payment operation (order transitions to the
processing
status, and the recurring transaction is initially in the
created
status).
Validate if the recurring transaction transitions to the
fail
status; otherwise, the order transitions to the
declined
status.
The user initiates a process for recurring payment that starts with an authorization step. This allows the merchant to verify the user's card and secure funds before automatically charging the card at specified intervals for ongoing services or subscriptions.
Test logic:
Execute the first payment using
auth/charge
and successfully authorize it; upon successful authorization, obtain a token (order in
auth_ok
status, and transaction auth in
success
status).
Use the token to execute a recurring payment with an additional authorization step (type
auth
) (order transitions to the
processing
status, and the recurring-auth transaction is initially in the
created
status).
Validate if the recurring-auth transaction transitions to the
fail
status; otherwise the order transitions to the
auth_failed
status.
The merchant initiates a refund procedure after confirming a successful payment transaction. This involves reversing the earlier charge and returning the funds to the customer's card or account.
Test logic:
Create an order and successfully process a payment (order should be in the
settle_ok
status, and both the
auth
and
settle
transactions should be in the
success
status).
Initiate a refund operation (refund transaction starts in the
created
status).
Validate if the refund transaction transitions to the
fail
status. If it does, confirm that the order remains in the
settle_ok
status; otherwise, it should transition to
refunded
.
By card brand
This section provides a list of test cards that can be used to verify the payment system.
To simulate payments that the issuer rejects for various reasons, use the test cards in this section. This can be useful to test the error-handling logic of your integration.
error:
{code: 0.01, message: “
Guide
The general group of declines. The card issuing bank did not complete the transaction successfully.
General decline
”}
error:
{code: 0.02, message: “
Guide
The user could not finalize the payment during the given timeframe, which resulted in order expiration.
Order expired
”}
error:
{code: 0.03, message: “
Guide
In some cases, the card issuer can block a transaction for law violation reasons. It can be due to a cardholder or due to a sanctioned country.
Illegal operation
”}
Validation errors
These errors indicate that invalid transaction data can typically be resolved by correcting the input data.
error:
{code: 2.06, message: “
Guide
The CVV code is the three-digit code on the back of a MasterCard or Visa, or the four-digit code on the front of an American Express.
Invalid CVV2 code
”}
error:
{code: 2.10, message: “
Guide
3DS URL was not displayed to the cardholder during 3D Secure authentication attempts.
Invalid 3DS Flow on the Merchant Side
”}
Transaction declines
Transaction declines arise from factors like card limits, insufficient funds, or fraud concerns, often necessitating bank contact or alternative payment methods.
card_number:
5361250317309261
card_exp_month:
09
card_exp_year:
2029
card_cvv:
629
card_bin:
REPUBLIC OF KOREA
error:
{code: 3.04, message: “
Guide
The transaction has been declined by the card issuer. Reasons for decline can vary, including limits on online payments, daily payment amounts, or daily transaction counts.
Transaction is declined by issuer
”}
error:
{code: 3.08, message: “
Guide
The card has been declined for an unknown reason.
Do not honor
”}
Suspected fraud
Test Data
Result
card_number:
4283184051091165
card_exp_month:
08
card_exp_year:
2028
card_cvv:
058
card_bin:
AUSTRALIA
error:
{code: 3.10, message: “
Guide
The issuing bank blocked the transaction due to possible fraud. The card was not in use for a long time, unusual activity, etc.
Suspected Fraud
”}
Fraud and anti-fraud
These errors indicate transactions flagged for potential fraud due to blacklisted cards, stolen cards, or triggered antifraud rules, requiring merchants to display a general decline and conduct further investigation or recommend customers to try again.
Stolen card
Test Data
Result
card_number:
4983102885450335
card_exp_month:
01
card_exp_year:
2029
card_cvv:
111
card_bin:
FRANCE
error:
{code: 4.02, message: “
Guide
The card in use is stolen, all transactions are restricted.
Stolen card
”}
error:
{code: 4.05, message: “
Guide
The acquiring bank blocked the transaction due to possible fraud. The card was not in use for a long time, unusual activity, etc.
PSP antifraud
”}
error:
{code: 4.07, message: “
Guide
An antifraud rule was triggered.
Trusted antifraud system
”}
Card blocked or restricted
These errors pertain to transactions blocked due to lost or restricted cards, requiring merchants to offer alternative payment options and check for potential fraud.
error:
{code: 4.04, message: "
Guide
The card in use is lost, all transactions are restricted.
Lost card
”}
Data or card verification
These errors relate to address mismatches, failed 3D verification, and issues with card tokens, requiring merchants to verify customer information, check for fraud, and consult support as needed.
error:
{code: 6.02, message: “
Guide
A connection is poor or interrupted.
Connection error
”}
Merchant configuration or activation errors
These errors are related to merchant configuration and API communication issues; resolution steps include contacting Solidgate Support or ensuring proper API method usage.