Endpoint responsible for creating a charge with credit card as the payment method.

This request can be used in two ways:

• by creating the charge and redirecting the payer to the invoiceUrl, where they will enter the card information in the Asaas interface
• by creating the charge with the card and cardholder data already sent in the request, allowing an immediate processing attempt

Ways to use this endpoint

The integration can choose either a flow with redirection to the invoice page or a flow with direct card data capture.

When the application sends the creditCard and creditCardHolderInfo objects, the authorization attempt is made at the time the charge is created.

When this data is not sent, the payment can be completed later through the invoice interface.

Main request parameters

In addition to the general charge fields, this endpoint accepts card-specific fields:

• creditCard — Object containing card data
• creditCardHolderInfo — Object containing cardholder data
• creditCardToken — Card token previously generated for secure reuse of the payment method
• authorizeOnly — When sent as true, performs only a pre-authorization of the amount
• remoteIp — Buyer's source IP. The final customer's IP must be sent, not the application server's IP

Immediate transaction processing

When the card and cardholder data are sent in the request, the processing attempt is made immediately.

• If the transaction is authorized, the charge will be created and the API will return HTTP 200
• If the transaction is not authorized, the charge will not be persisted and the API will return HTTP 400

Cardholder data validation

The data sent in creditCardHolderInfo must match the data registered with the card issuer.

If there is a relevant mismatch, the transaction may be denied due to suspected fraud. This is especially important in transparent checkout integrations.

Important rule regarding the due date

Regardless of the date informed in dueDate, charge capture on the card occurs at the moment the charge is created when the integration sends the card data for immediate processing.

In other words, the due date field does not postpone the charge on the card in this type of flow.

Card tokenization

After a first successful card transaction, the Asaas response may return the creditCardToken attribute.

This token can be stored and reused in future transactions, replacing the creditCard and creditCardHolderInfo objects. This reduces the need to transmit sensitive card data again and simplifies subsequent flows.

The token is stored per customer and cannot be used in transactions for other customers.

Security requirements

If the application captures card data in its own interface, HTTPS is mandatory.

❗️

Attention

Without SSL, the account may be blocked from processing credit card transactions.

This requirement must be observed in any proprietary checkout flow that handles sensitive payer data.

Recommended timeout

To reduce the risk of timeout and avoid duplicate capture attempts, the recommendation is to configure a minimum timeout of 60 seconds for this request.

Credit card installments

It is possible to create credit card installment plans with different limits depending on the card brand:

• Visa and Master cards: up to 21 installments
• other card brands: up to 12 installments

This behavior must be considered by the integration when building the installment options available to the end user.

Pre-authorization

When the authorizeOnly field is sent as true, the charge is created in pre-authorization mode.

In this flow, the amount is not captured immediately. Instead, an amount is reserved from the customer's card limit and may be captured later.

A charge created with pre-authorization will have the AUTHORIZED status after successful creation.

Pre-authorization period

The pre-authorization period defines how long the amount will remain reserved on the card limit.

The default period is 3 days. For eligible accounts, this period can be configured up to 25 days, according to card brand rules and the account's classification under specific MCCs.

If the capture does not take place within the configured period, the reservation will be automatically reversed.

This configuration applies only to new pre-authorizations and does not affect charges that have already been created.

Sandbox

In sandbox, transactions are automatically approved.

To simulate errors, the test card numbers provided in the documentation must be used.