Quickstart: Create a payment
This guide helps you create your first successful payment transaction. You'll authenticate with the API, submit a payment request, and verify the transaction status.
Step 1: Get a credential
After your account is activated, you receive your Test Account and API keys, which let you start the integration.
Important: Step 1 is only available for Argentina, Chile, and Mexico.
To generate the credential, follow these steps in the Getnet Merchant Portal:
Important: This screen shows all contracted products. Credential generation is enabled by solution.

- Select Digital Products.
- In the dropdown menu, select Integrations.
- Click Generate credentials.
- In the pop-up warning, click Generate credentials.
- The portal creates your credential. Save it, because the portal can't show it again.
- Copy and paste the Client ID.
- Copy and paste the Client Secret.
- Click Continue.
Info: If you lose the keys, repeat these steps to generate a new credential.
Step 2: Get an access token
Info: You can also retrieve an access token with other requests. To learn more about these requests, see the Authentication document.
Request example
Response example
Step 3: Create a payment intent
The payment intent allows the frontend to load the Checkout interface and proceed with the transaction securely.
A payment intent ensures that the customer is charged the exact amount you set when you create it. You generate the payment intent on the backend, so the amount stays the same throughout the payment flow. No one can change it from the frontend, either accidentally or maliciously.
access_token you got earlier in the Authorization header. A successful response returns the payment intent ID and redirect URL. Your frontend implementation requires these values, depending on the integration method you choose.For more details, see the API reference.
| Endpoint |
|---|
POST /payment-intent |
| Field | Type | Description | Example |
|---|---|---|---|
payment.currency | String | Currency code. | BRL |
payment.amount | Integer | Purchase amount in integer format, where the last 2 digits represent the cents. For countries where cents do not apply, fill in the amount with 2 zeros to the right. | 92500 |
customer.customer_id | String | We recommend the customer's document number. Use only letters and numbers, without special characters, separators, or spaces. | 12345678912 |
customer.first_name | String | Customer's first name. | John |
customer.last_name | String | Customer's last name. | Doe Smith |
customer.name | String | Customer's full name. | John Doe Smith |
customer.email | String | Customer's email address. | customer@email.com.br |
customer.document_type | String | Type of the document used to identify the customer. Check the Field Values table to see the accepted values. | CPF |
customer.document_number | String | Document number used to identify the customer. | 12345678912 |
customer.billing_address.street | String | Name of a street. | Av. Brasil |
customer.billing_address.number | String | Number that identifies the position of a building on a street. | 1000 |
customer.billing_address.country | String | Country code. Check the Field Values table to see the accepted values. | BR |
customer.billing_address.postal_code | String | Postal or ZIP code. | 90230060 |
| Field | Type | Description | Example |
|---|---|---|---|
additional_data | Object | Additional data for regional regulations and tax requirements. Required for Uruguay. | --- |
additional_data.rates | Array | Tax rates applied to the transaction. | --- |
additional_data.rates.key | String | (Uruguay only). Type of tax or rate being applied. | IVA |
additional_data.rates.value | Number | (Uruguay only). Tax amount in integer format (cents). | 123 |
additional_data.regional_regulation_code | String | (Uruguay only). Regional fiscal or regulatory code required by local authorities. Used for SEP submissions in Uruguay. | 17934 |
| Field | Type | Description | Example |
|---|---|---|---|
configurations | Object | Additional configurations for the payment intent. | --- |
configurations.3ds | Boolean | Controls 3D Secure authentication. | true or false |
configurations.preauthorization | Boolean | Indicates if the payment is a pre-authorization. | true or false |
configurations.card_verification | Boolean | Indicates if this is a card verification flow. | true or false |
configurations.success_url | String | Redirect URL in case of successful payment. | https://www.mystore.com/checkout/success |
configurations.error_url | String | Redirect URL in case of an error during payment. | https://www.mystore.com/checkout/error |
expires_at | String | Payment intent expiration. | 3d4h15m |
| Field | Argentina | Brazil | Colombia | Chile | Europe | Mexico | Uruguay |
|---|---|---|---|---|---|---|---|
currency | ARS | BRL | COP | CLP | EUR | MXN | UYU or USD |
document_type | DNI | CPF, CNPJ or passport | CC, PP, RC, DE, CE, TI, NIT, IDC or CEL | RUT | DNI, INE or passport | RFC | uyci |
country | AR | BR | CO | CL | PT and ES | MX | UY |
key | - | - | - | - | - | - | IVA |
Field filling rules
The following rules apply to some of the fields above.
- The
expires_atfield accepts a duration value (for example, 15m, 2h, 7d, or 1d12h30m). The API applies this duration regardless of the merchant's timezone. The expiration timestamp returned by the API is always formatted in GMT+0 (UTC). If you provide no value, the payment intent does not expire. - When you provide
success_urlanderror_urlin the payment intent request, they override the values configured in the seller's technical configuration. - Uruguay: You can create payment intents in either UYU (Uruguayan Peso) or USD. For payments in UYU, the
additional_dataobject is required. It must includeadditional_data.rates.keywith the IVA rate key andregional_regulation_codefor SEP compliance. - Argentina:
card_verificationandpreauthorizationare not available for Argentina.
Response example
Step 4: Integrate the frontend
redirect_url and payment_intent_id. You need them to integrate Getnet’s Web Checkout into your frontend.The property you use depends on the integration format you choose, implemented with JavaScript or React.
- For the Redirect (Getnet-hosted) Web Checkout, use the URL in the
redirect_urlproperty to open a new page for the shopper. - For the iFrame or Lightbox formats, extract the
payment_intent_idfrom the response. Then follow the corresponding steps to embed the Checkout interface on your web store’s payment page.
Import the Getnet loader
host_getnet_web:- https://www.pre.globalgetnet.com (homologation environment)
- https://www.globalgetnet.com (production environment)
Then, add the following code:
Add the checkout script
The checkout script connects the loader and the user. It also lets you select the integration option that best fits your needs.
paymentIntentId value with the payment_intent_id you received earlier. Set the checkoutType value to lightbox or iframe, depending on your selection:Add the checkout button
The button runs the checkout script from the previous step. Add the following code to your HTML:
Change the position of the iFrame
The example below shows how to create the iFrame with an identifier and manipulate it in the DOM.
Transaction flow
A payment goes through the following steps.
- The payment process begins when the buyer clicks the designated payment button.
- The checkout screen displays the payment intent value and the available payment methods, based on your Merchant Portal or API configuration.
- For credit or debit card payments, the buyer enters their card details. If the card brand and type support installment payments, a transparent query is sent to Getnet's Installments API. This query retrieves the available installment options for this checkout.
- The installments offered are based on your agreements with Getnet and on your Merchant Portal or API configurations. In those configurations, you choose whether to offer installments with or without interest. You also set a limit on the number of installments.
- When the buyer clicks the button, the payment authorization process starts.

Payment authorization process in Getnet Web Checkout
- Device Fingerprint Capture: Collects device information to support fraud analysis.
- 3D Secure Authentication (3DS): Applied when supported by the card’s country of origin, brand, issuer, and type.
- Card Tokenization: In compliance with PCI DSS standards, sensitive card data is neither transmitted nor stored during the authorization process. Instead, the card is tokenized at the start of the flow, and only the generated token is transmitted between internal APIs.
- Payment Method Validation: Verifies that the selected payment method, card brand, and installment plan are compatible with the products and services contracted by the merchant.
- Fraud Analysis: Conducted via Getnet’s Antifraud API, based on rules defined by the relevant Getnet team in each country.
- Payment Authorization: The final step, where the transaction is authorized through communication with the appropriate financial institutions.
- Failure: If the payment is declined or an issue is detected during the process, the buyer sees an error message. A webhook or notification is also sent with the payment details and the transaction status.
- Success: If the payment is authorized, the buyer sees a confirmation message. A webhook or notification is also sent with the authorization data and transaction status. At this stage, the payment_id is generated. You can use it for cancellation or refund operations. For details, see the Modifying Payments documentation.
On this page