Developer platform

The API is the core.
The experience remains yours.

Build payments directly into your product. A API REST for customers, cards, Pix, boleto and credit with SDKs, webhooks and dedicated references for Transactional, Payment Links, Sellers, Payment Split and Expense Management.

Start with API ↓ Open the Reference API —

REST APISandboxNode.jsPHP / LaravelWebhooksPayment LinksPayment Split

POST /api/v1/transaction/new/:CustomerID

new credit card transaction

application/json

{
  "amount": 14990,
  "currency": "BRL",
  "description": "Pedido #102938",
  "id_card": "23082eb67cd54e7eb4c9cf8c760bd12f",
  "capture": 1,
  "statement_descriptor": "IOPAY STORE",
  "installment_plan": {
    "number_installments": 1
  },
  "io_seller_id": "<IO_SELLER_ID>",
  "payment_type": "credit",
  "reference_id": "102938"
}

application/json Transaction response

{
  "success": {
    "id": "7f38b2c94e1a4d69a81f53b76d9c204e",
    "resource": "transaction",
    "status": "succeeded",
    "payment_type": "credit",
    "amount": "149.90",
    "captured": true,
    "currency": "BRL",
    "reference_id": "102938",
    "payment_method": {
      "resource": "card",
      "card_brand": "Visa",
      "last4_digits": "4242"
    },
    "installment_plan": {
      "mode": "interest_free",
      "number_installments": "1"
    },
    "created_at": "2026-10-06T20:09:48+00:00"
  }
}

Card without recapturing data.Use id_card already associated with customer and create the transaction.

IOPAY Documentation

APIs and Documented and Organized Integration References

Expand payment products and services as a service. Start with API Base and move on to the specific reference for its implementation. Transactional, Payment Links, Sellers, Payment Split, Consultations, Tokenization and Expense Management are organized you quickly get to the right reference.

docs-api.iopay.com.br

Public documentation

Core API

The foundation of their integration.

It starts with authentication, setting up environment, customers, cards and tokenization. The transaction layer enters the next stage.

Open the Reference API —

The FoundationCore API

AUTHBearer tokenAccess

POSTv1/customer/newCustomer

POSTv1/card/tokenize/tokenTokenize

ENVsandbox / productionEnvironments

Transactional API

From the payment created to the full transaction cycle.

Concentrate here the transactional operations of Pix, card and boleto: creation, consultation, capture, cancellation, return and status monitoring.

Open the Transactional API —

PaymentsTransactional API

POSTv1/transaction/new/:CustomerIDCreate

GETv1/transaction/get/:idView

CAPcaptura total ou parcialCapture

VOIDcancelamento / estornoCycle

Postman · Payment Links API V2

Turn a charge into a URL.

API V2 includes link creation, query, update, deletion and listing, as well as query of the transactions generated. Set up items, means of payment, installment, interest, availability, Order Bump, visual identity and Split when enabled.

Open the V2 documentation — Reference V1 —

V2 configurationPayment Link

ITEMtitle + items[]Payment request

PAYcredit / pix / boletoMethods

TIMEopen_at / end_at / max_paymentsAvailability

CARDmax_installment + interestInstallments

BUMPorder_bump_items[]Additional offer

BRANDprimary_color + bannersIdentity

SPLITsplit_rules[]Distribution

Postman · Sellers API

Participants treated as part of the architecture.

See the specific reference for implementing Sellers related platform features and keeping this layer separate from the transactional core.

Open Sellers at the Postman —

Public collection

Sellers APIParticipants of the platform

Postman · Payment Split

Payment Split with own reference.

Use the dedicated collection to implement Payment Split rules in multi-participant operations, keeping this layer separate from API Base and Transactional API.

Open Payment Split in the Postman —

Public collection

Payment Splitthe rules for Payment Split

Expense Management & Corporate Cards

Corporate control connected to the platform.

A dedicated front for the issuance and management of corporate cards, setting limits, policies for use, carriers and monitoring of expenditure.

Opening up Spending Management

CorporateCorporate Cards

CARDemissão e gestão por empresaCards

RULElimites e políticas de usoControl

TEAMportadores e centros de custoTeam

VIEWvisão consolidada de gastosOperations

Quick start

From the first request
the first charge.
In three steps.

Set up authentication, create customer and manage an Pix charge using the same flow your application will take to production.

First integration

A shortcut to understanding API's structure before exploring the other features.

Open the Reference API —

Step 01 · Access

Authentication of requests

Every integration starts with the right environment and a valid token in the Authorization header.

Bearer tokenSandboxProduction

Goal

Your application is now authenticated to API IOPAY.

Expected return

From here, you can call the next routes of integration.

Where does it go?

At the beginning of any integration, before creating customers or transactions.

Checklist of the

Choose sandbox or production.
Add Authorization: Bearer seu_token.
Submit Content-Type: application/json.

Example of authentication

Docs —

curl --request GET \
  --url https://api.iopay.com.br/api/v1/customer/get/:customerId \
  --header 'Authorization: Bearer seu_token' \
  --header 'Content-Type: application/json'

Next step

With the authentication ready, the next step is to create the buyer who will receive the charge.

Authorization: Bearer seu_token

Means of payment

It's an integration.Every payment,
Your own journey.

Pix, card and boleto live in the transactional core. Payment Linkss carry the same infrastructure for assisted sales, remote charging and channels without own checkout.

PIX

Pix

Create instant bills, QR Code and follow up confirmation by event.

Ideal for checkout, remote billing and instant payment flows.

Cards

Single-payment credit or parcelling, tokenization and repurchase or recurrence journeys.

It allows you to combine own checkout with the authorisation flows of the operation.

BLT

Boleto

The issuance and follow-up of charges for journeys requiring payment of title.

The statement of receipt may be integrated into the internal processes of the company.

LNK

Payment Links

Create shared, hosted charges for API to sell outside of the traditional checkout.

CRM, WhatsApp, inside sales, service and attended travel.

Webhooks & events

Your system doesn't need to ask.
Iopay will be alerted in seconds.

HTTP POST Real time No polling

IOPAY receives the payment update, processes the new status and sends webhook to its endpoint. Low friction, clear flow and synchronized systems.

Count on the webhooks layer and resilient Iopay events with automatic re-delivery in cases of your server unavailability.

01 · Origin The pay is changing.

New state of the infrastructure.

→→→→→→→→→→→→→→

03 · Its system The webhook is here. I always do.

Your endpoint receives the POST request from Iopay and you process and react as you please. Your system takes action after a payment has been created, approved, failed, withdrawn or partially cancelled. With confimation your system has everything to release the request, feed CRM & ERPs, interact with SAP, integrate fullfilment and tax return.

SDKs IOPAY

SDKs for Java, JavaScript, Node.js and
PHP / Laravel.

Use the public IOPAY clients in Node.js and PHP / Laravel or integrate directly by API REST in any language. Less boilerplate to start with, without losing access to the HTTP platform contract.

The official SDK · Node.js

Ready to integrate with JavaScript applications.

Public client with authentication, environments, tokenization, customers and major transactional operations.

See it on GitHub —

Installation

npm install
@iopay-payments/iopay-api-sdk-nodejs

// depois, use o client IOPAY no projeto

Official SDK · PHP

Composer for PHP or Laravel Projects.

The official package iopay-payments/sdk-php can be installed via Composer and used by the project auto load, including in Laravel applications.

See it on GitHub — Packagist —

Installation by Composer

composer require
iopay-payments/sdk-php

// disponível no vendor/autoload.php do projeto

REST API · any stack

Use HTTP direct whenever you want total control.

Python, Go, Java, .NET, Ruby or any other stack can consume API IOPAY directly via HTTPS, using the same published endpoints and contracts.

Open the Reference API —

Universal example

curl --request GET \\
  --url https://api.iopay.com.br/api/v1/customer/get/:CustomerID \\
  --header 'Authorization: Bearer seu_token' \\
  --header 'Content-Type: application/json'

Operations

Integration and operation need to speak the same language.

After the deployment, engineering, product, finance and service need to see the same payoff. The IOPAY portal complements API with transactional vision, receivables, credentials, reports and operational monitoring.

01Transactions Please consult the status, client, method, value and references of the transaction.

02Receivables Keep track of the financial outlook associated with the processed sales.

03Credentials Centralize the data needed for integration environments.

04Reports Support routine operations and reconciliation without relying solely on the engineering team.

Operations IOPAYConsolidated vision

TRANSACTIONS883

APPROVAL60,4%

TPVR$ 2,58M

TransactionMethodStatus of theAmount

0b527...9a6creditApprovedR$ 1.002

44d23...9044pixOtherR$ 3.482

34fad...29e7creditApprovedR$ 5.444

Security & architecture as core and foundation principle

APIs and architecture designed to operate
payments with control, security and vision.

Credentials, environment segregation, tokenization and security controls are part of the product architecture and reduce unnecessary exposure to sensitive data.

01Separated credentials

Separate development, testing and production with credentials appropriate to each environment.

02Tokenization

Reduces the flow of sensitive data in buyback, retrieval and one-click journeys.

03PCI DSS 4.0.1

Payment security and environmental protection controls applied to the IOPAY infrastructure.

04Events and traceability

Use identifiers, status and webhooks to track the transaction cycle and respond to exceptions.

Use cases

Architecture for different
business models.

The Developer Platform IOPAY is designed for products that need to incorporate payments into the e-commerce experience itself to SaaS, marketplace, ERP and assisted sales.

E-commerce

Checkout yourself.

Control the buyer's experience while IOPAY runs the payment and event layer.

See e-commerce →

SaaS & recurrence

Recharge and continuous charge.

It combines tokenization, customers, events, and logic of its application for recurring journeys.

Sellers and Payment Split.

Take the context of Sellers and the rules of Payment Split into account for the transaction flow.

See marketplaces →

ERP & finance

Payments connected to the operation.

Integrate bills and events into internal settlement, service and financial processes.

Speaking to an expert →

Inside sales

Charge inside the funnel.

Manage links or transactions from the CRM and return status for sales, onboarding and finance.

Infrastructure under your experience.

Combine APIs and platform features to offer paid journeys integrated with your brand.

See white-label →

Technical content

To bring about its integration
From the first call to production.

Four readings from the IOPAY blog selected for those designing payment integrations, asynchronous events, security and developer experience.

Architecture and production

How to integrate payments into your system via API

From sandbox to go-live: states, idempotence, retries, rows, observability, reconciliation and treatment of exceptions in production.

Read the article↗

Webhooks & events

Payment webhooks: security, idempotence and retries

How to receive events securely, deal with duplicity, delays, redirects, and keep the app's status consistent.

Read the article↗

Developer experience

SDK or REST API for payments: which to choose?

Compare implementation speed, control level, versioning, maintenance, observability and portability between approaches.

Read the article↗

API security

Security of payment APIs

Authentication, secrecy, rate limiting, idempotence, authorisation and controls are essential to safeguard financial integration.

Read the article↗

Integration and APIs IO

From the first call to production. Count on the best payment solution architecture

Explore the documentation, test its integration, and ease payments into your product with IOPAY infrastructure.

Open your account ↗API Reference

The API is the core.The experience remains yours.

APIs and Documented and Organized Integration References

The foundation of integration

Payment cycle

Payment Links

Logistics and Buyers

Payment Split

Corporate Cards

The foundation of their integration.

From the payment created to the full transaction cycle.

Turn a charge into a URL.

Participants treated as part of the architecture.

Payment Split with own reference.

Corporate control connected to the platform.

From the first requestthe first charge.In three steps.

Authentication of requests

It's an integration.Every payment,Your own journey.

Pix

Cards

Boleto

Payment Links

Your system doesn't need to ask.Iopay will be alerted in seconds.

SDKs for Java, JavaScript, Node.js and PHP / Laravel.

Ready to integrate with JavaScript applications.

Composer for PHP or Laravel Projects.

Use HTTP direct whenever you want total control.

Integration and operation need to speak the same language.

APIs and architecture designed to operatepayments with control, security and vision.

Architecture for differentbusiness models.

Checkout yourself.

Recharge and continuous charge.

Sellers and Payment Split.

Payments connected to the operation.

Charge inside the funnel.

Infrastructure under your experience.

To bring about its integrationFrom the first call to production.

How to integrate payments into your system via API

Payment webhooks: security, idempotence and retries

SDK or REST API for payments: which to choose?

Security of payment APIs

From the first call to production. Count on the best payment solution architecture

1. Who we are

2. What data can we process

3. For what purposes do we use personal data

4. Legal basis

5. Sharing of data

6. Storage and retention

7. Security

8. Cookies and similar technologies

9. Rights of the holder

10. How to Talk to Us

11. Updates to this policy

1. What are cookies

2. Categories used by IOPAY

3. Consent and preferences

4. Amendment or revocation

5. Cookies of third parties

6. Time and storage of preferences

7. Other information

1. Data protection commitments

2. Role of IOPAY in the treatment

3. Rights of the holder

4. How to exercise your rights

5. Conservation limits and possibilities

6. Security and governance

7. Security incidents

8. Updates

The API is the core.
The experience remains yours.

From the first request
the first charge.
In three steps.

It's an integration.Every payment,
Your own journey.

Your system doesn't need to ask.
Iopay will be alerted in seconds.

SDKs for Java, JavaScript, Node.js and
PHP / Laravel.

APIs and architecture designed to operate
payments with control, security and vision.

Architecture for different
business models.

To bring about its integration
From the first call to production.