IOPAY→APIs
Developer platform

The API is the core.

The experience stays yours.

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

Start with the API ↓ Open API Reference ↗
REST APIProductionSandboxWebhooksCards in up to 21xPixBoletoTokenization and 1-Click PurchasePayment LinksPayment Split
IOPAY Documentation

Documented and Organized APIs and Integration References

Expand payment products and services as a service. Start with the Base API and move on to the reference specific to your implementation. Transactions, Payment Links, Sellers, Payment Split, Queries, Tokenization and Spend Management are organized so you quickly reach the right reference.

docs-api.iopay.com.br
Public documentation
Base API

The foundation of your integration.

Start with authentication, environment setup, customers, cards and tokenization. The transactional layer comes in the next step.

Open API Reference ↗
FoundationBase API
AUTHBearer tokenAccess
POST/api/v1/customer/newCustomer
POST/api/v1/card/tokenize/tokenTokenize
ENVsandbox / productionEnvironments
Transactional API

From the payment created to the full transaction lifecycle.

Concentrate here the transactional operations for Pix, cards and boleto: creation, query, capture, cancellation, refund and status tracking.

Open Transactional API ↗
PaymentsTransactional API
POST/api/v1/transaction/new/:CustomerIDCreate
GET/api/v1/transaction/get/:idQuery
CAPfull or partial captureCapture
VOIDcancellation / refundLifecycle
Postman · Payment Links API V2

Turn a charge into a URL.

API V2 brings together creating, querying, updating, deleting and listing links, plus querying the transactions they generate. Configure items, payment methods, installments, interest, availability, Order Bump, visual identity and Split when enabled.

Open V2 documentation ↗ V1 reference ↗
V2 setupPayment Link
ITEMtitle + items[]Charge
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.

Check the specific reference to implement resources related to the platform's Sellers and keep that layer separate from the transactional core.

Open Sellers in Postman ↗
Postman Public collection
Sellers APIplatform participants
Postman · Payment Split

Payment Split with its own reference.

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

Open Payment Split in Postman ↗
Postman Public collection
Payment SplitPayment Split rules
Spend Management & Corporate Cards

Corporate control connected to the platform.

A dedicated front for issuing and managing corporate cards, setting limits, usage policies, cardholders and tracking the spending operation.

Open Spend Management ↗
CorporateCorporate Cards
CARDissuance and management per companyCards
RULElimits and usage policiesControl
TEAMcardholders and cost centersTeam
VIEWconsolidated view of spendingOperation
Quickstart

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

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

Step01of 03 ·Authenticate requests
Step 01 · Access

Authenticate requests

Every integration starts by authenticating your credentials to obtain the API access token.

Bearer TokenTransaction3600s
What to do in this step
  • Send email, secret and io_seller_id.
  • Receive the access_token.
  • Use the Bearer Token in the next requests.
Understand this step
Goal
Your application starts talking to the IOPAY API in an authenticated way.
Expected response
An access token to authenticate the next requests.
Where it fits
At the start of the integration, before accessing customers, cards or transactions.
Authentication example
Docs ↗

        

        
Sample response · JSON

      

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

    

  










Payment methods
One integration.Each payment,
its own journey.
Pix, cards and boleto live in the transactional core. Payment Links take the same infrastructure to assisted sales, remote charges and channels without their own checkout.
PIX
Pix
Creation of instant charges, QR Code and confirmation tracking by event.
Ideal for checkout, remote charges and immediate payment flows.
CC
Cards
Single-payment or installment credit, tokenization and repurchase or recurring journeys.
Lets you combine your own checkout with the operation's authorization flows.
BLT
Boleto
Issuance and tracking of charges for journeys that require payment by bank slip.
The charge status can be integrated into the company's internal processes.
LNK
Payment Links
Create hosted, shareable charges via API to sell outside the traditional checkout.
CRM, WhatsApp, inside sales, support and assisted journeys.






  

    

      

        Webhooks & events
        
Your system doesn't need to ask.
Iopay notifies you in seconds.

        

          HTTP POST
          Real time
          No polling
        

      

      
IOPAY receives the payment update, processes the new state and sends the webhook to your endpoint. Little friction, a clear flow and synchronized systems.

      
       
Count on Iopay's resilient webhooks and events layer, with automatic redelivery when your server is unavailable.

    


    

      

        01 · Origin
        The payment changes.
        
New state in the infrastructure.

      

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

      

        03 · Your system    
        The webhook arrives. Always.
        
Your endpoint receives the POST request from Iopay and you process and react as you wish. Your system takes action after a payment is created, approved, failed, refunded or partially canceled. With the confirmation, your system has everything it needs to release the order, feed CRM & ERPs, interact with SAP, integrate fulfillment and invoicing.

      

    

  
  






  

    

      

        SDKs IOPAY
        
SDKs for Java, Javascript, Node.js and
 PHP / Laravel.

        
Use IOPAY's public clients in Node.js and PHP / Laravel or integrate directly through the REST API in any language. Less boilerplate to get started, without losing access to the platform's HTTP contract.

        
      


      

        

          
          
          
        


        

          

            Official SDK · Node.js
            
Ready-made integration for JavaScript applications.

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

            

              View 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 through the project's autoload, including in Laravel applications.

            

              View on GitHub ↗
              Packagist ↗
            

          

          

            Installation via Composer
            
composer require
iopay-payments/sdk-php

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

          

        


        

          

            REST API · any stack
            
Use plain HTTP when you want full control.

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

            

              Open API Reference ↗
            

          

          

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

          

        


      

    
 
  






Operation
Integration and operations need to speak the same language.
After deployment, engineering, product, finance and support need to see the same payment. The IOPAY portal complements the API with a transactional view, receivables, credentials, reports and operational tracking.
01Transactions Check status, customer, method, amount and operation references.
02Receivables Track the financial view associated with processed sales.
03Credentials Centralize the data required for the integration environments.
04Reports Support operations and reconciliation routines without depending only on the engineering team.
IOPAY OperationsConsolidated view
TRANSACTIONS883
APPROVAL60,4%
TPVR$ 2.58M
TransactionMethodStatusAmount
0b527...9a6creditApprovedR$ 1,002
44d23...9044pixPendingR$ 3,482
34fad...29e7creditApprovedR$ 5,444


Security & architecture as the core and founding principle
APIs and architecture designed to operate
payments with control, security and visibility.
Credentials, environment segregation, tokenization and security controls are part of the product architecture and reduce unnecessary exposure of sensitive data.
01Segregated credentials
Separate development, testing and production with credentials suited to each environment.
02Tokenization
Reduce the circulation of sensitive data in repurchase, recurring and one-click journeys.
03PCI DSS 4.0.1
Security controls and payment environment protection applied to the IOPAY infrastructure.
04Events and traceability
Use identifiers, statuses and webhooks to track the transaction lifecycle and respond to exceptions.


Use cases
Architecture for different
business models.
The IOPAY Developer Platform was designed for products that need to embed payments into their own experience, from e-commerce to SaaS, marketplaces, ERP and assisted sales.
E-commerce
Your own checkout.
Control the buyer experience while IOPAY runs the payments and events layer.
See e-commerce →
SaaS & recurring payments
Repurchase and continuous billing.
Combine tokenization, customers, events and your application logic for recurring journeys.
See documentation →
Marketplaces
Sellers and Payment Split.
Bring the Sellers context and Payment Split rules into the transaction flow.
See marketplaces →
ERP & finance
Payments connected to operations.
Integrate charges and events into internal reconciliation, support and finance processes.
Talk to an expert →
Inside sales
Charging inside the funnel.
Generate links or transactions from the CRM and return status to sales, onboarding and finance.
See links →
White-label
Infrastructure under your experience.
Combine APIs and platform resources to offer payment journeys integrated with your brand.
See white-label →



  

    

      

      
        



      
        Technical content
        
To take your integration
from the first call to production.

      

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

    


    

      
        Architecture & production
        
How to integrate payments into your system via API

        
From sandbox to go-live: states, idempotency, retries, queues, observability, reconciliation and exception handling in production.

        
Read article↗

      

      
        Webhooks & events
        
Payment webhooks: security, idempotency and retries

        
How to receive events securely, handle duplicates, delays and redeliveries, and keep the application state consistent.

        
Read article↗

      

      
        Developer experience
        
SDK or REST API for payments: which to choose?

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

        
Read article↗

      

      
        API security
        
Payment API security

        
Authentication, secrets, rate limiting, idempotency, authorization and essential controls to protect a financial integration.

        
Read article↗

      
    


    

      See more about APIs ↗
    

  




IO Integration and APIs
From the first call to production. Count on the best payment solutions architecture
Explore the documentation, test your integration and bring payments into your product with IOPAY infrastructure.
Open your account ↗API Reference