Testing credit card payment
Use test cards to validate credit card charges without moving real money.
In this flow, you can test approvals, declines, API responses, and the processing of Webhooks related to the charge.
By the end of this guide, you will have tested the approval and decline scenarios for a credit card charge.
When to use it
Use this flow to validate:
- one-time charges;
- subscriptions and recurring payments;
- card tokenization;
- your own checkout;
- handling of approvals and declines;
- updates received via Webhook.
Before you start
You need to:
- Have a Sandbox account and API key.
- Create a customer to link to the charge.
- Configure the Webhooks used by the integration.
- Use the credit card charge endpoint.
See Create charge with credit card.
Use only fictitious cards and data.
Never use real customer information during validation testing.
1. Create the charge
In the request, provide the customer, charge, and card data.
The main fields are:
| Field | Purpose |
|---|---|
customer | ID of the customer linked to the charge |
billingType | Must be CREDIT_CARD |
value | Charge amount |
dueDate | Due date |
creditCard | Data of the card used |
creditCardHolderInfo | Cardholder data |
See the endpoint reference for all fields and filling rules.
2. Simulate an approval
To simulate an approved transaction, use a valid fictitious card number. You can generate a test card using tools such as the 4Devs Credit Card Generator.
Use the following data:
| Information | Value |
|---|---|
| Card number | Valid fictitious card number |
| Expiration date | Any future date |
| CCV | 123 or any other three-digit number |
The Sandbox should simulate successful processing of the charge.
Use only fictitious cards and data during testing. Do not use real card data in the Sandbox environment.
3. Simulate a decline
Use one of the cards below:
| Brand | Number |
|---|---|
| Mastercard | 5184019740373151 |
| Visa | 4916561358240741 |
These numbers let you test how processing failures are handled.
4. Validate the result
After sending the request:
- check the HTTP status and the response body;
- store the charge ID;
- track the charge status;
- receive the corresponding Webhook;
- confirm that your application processed the result correctly.
Create customer
↓
Create card charge
↓
Receive API response
↓
Receive Webhook
↓
Update the status in the applicationDo not rely only on the synchronous response to complete processing.
Also take into account the events received via Webhook and later changes to the charge status.
Expected behavior
In the Sandbox:
- test cards determine the simulated result;
- no acquirer is contacted;
- no real money is moved;
- responses are exclusively for validation testing.
At a minimum, test:
| Scenario | What to validate |
|---|---|
| Approval | Charge update and Webhook processing |
| Decline | Returned message and failure handling |
| Repeated Webhook | Idempotent processing |
| Unexpected error | Logs, alerts, and application behavior |
Differences between Sandbox and Production
| Sandbox | Production |
|---|---|
| Uses test cards | Uses real cards |
| Simulates approvals and declines | Depends on real processing |
| Does not move money | Moves real money |
| Does not contact acquirers | Depends on card networks and acquirers |
A card approval in the Sandbox does not guarantee that a similar transaction will be approved in Production.
Validation checklist
Before considering the flow validated, confirm that your application:
- handles approvals and declines;
- processes Webhooks idempotently;
- records operation IDs and timestamps;
- does not store sensitive card data;
- shows appropriate messages to the payer;
- has logging and monitoring;
- is prepared for different responses in Production.
Next steps
Updated 17 days ago