Developer Platform

Die API ist der Kern.

Das Erlebnis bleibt Ihres.

Bauen Sie Zahlungen direkt in Ihr Produkt ein. Eine REST-API für Customers, Karten, Pix, Boleto und Kredit, mit SDKs, Webhooks und eigenen Referenzen für Transaktionen, Zahlungslinks, Seller, Zahlungs-Split und Ausgabenmanagement.

REST APIProduktionSandboxWebhooksKarten in bis zu 21xPixBoletoTokenisierung und Kauf mit 1 KlickZahlungslinksZahlungs-Split
IOPAY-Dokumentation

Dokumentierte und geordnete APIs und Integrationsreferenzen

Erweitern Sie Zahlungsprodukte und -dienste als Service. Beginnen Sie mit der Basis-API und gehen Sie dann zur spezifischen Referenz Ihrer Implementierung. Transaktionen, Zahlungslinks, Seller, Zahlungs-Split, Abfragen, Tokenisierung und Ausgabenmanagement sind so geordnet, dass Sie schnell zur richtigen Referenz gelangen.

docs-api.iopay.com.br
Öffentliche Dokumentation
Basis-API

Die Grundlage Ihrer Integration.

Beginnen Sie mit Authentifizierung, Umgebungseinrichtung, Customers, Karten und Tokenisierung. Die Transaktionsschicht folgt im nächsten Schritt.

FoundationBasis-API
AUTHBearer tokenZugang
POST/api/v1/customer/newCustomer
POST/api/v1/card/tokenize/tokenTokenize
ENVsandbox / productionUmgebungen
Transaktions-API

Von der erstellten Zahlung zum kompletten Transaktionszyklus.

Bündeln Sie hier die Transaktionsvorgänge für Pix, Karte und Boleto: Erstellung, Abfrage, Erfassung, Stornierung, Erstattung und Statusverfolgung.

PaymentsTransaktions-API
POST/api/v1/transaction/new/:CustomerIDErstellen
GET/api/v1/transaction/get/:idAbfragen
CAPvollständige oder teilweise ErfassungErfassung
VOIDStornierung / ErstattungZyklus
Postman · Payment Links API V2

Machen Sie aus einer Zahlungsanforderung eine URL.

Die API V2 umfasst Erstellen, Abfragen, Aktualisieren, Löschen und Auflisten von Links sowie die Abfrage der erzeugten Transaktionen. Konfigurieren Sie Artikel, Zahlungsarten, Ratenzahlung, Zinsen, Verfügbarkeit, Order Bump, visuelle Identität und Split, sofern aktiviert.

Konfiguration V2Payment Link
ITEMtitle + items[]Zahlungsanforderung
PAYcredit / pix / boletoMethoden
TIMEopen_at / end_at / max_paymentsVerfügbarkeit
CARDmax_installment + interestRatenzahlung
BUMPorder_bump_items[]Zusatzangebot
BRANDprimary_color + bannersIdentität
SPLITsplit_rules[]Verteilung
Postman · Sellers API

Beteiligte als Teil der Architektur.

Nutzen Sie die spezifische Referenz, um Ressourcen für die Seller der Plattform zu implementieren und diese Schicht vom Transaktionskern getrennt zu halten.

Postman Public collection
Sellers APIBeteiligte der Plattform
Postman · Zahlungs-Split

Zahlungs-Split mit eigener Referenz.

Nutzen Sie die dedizierte Collection, um Regeln für den Zahlungs-Split bei Abläufen mit mehreren Beteiligten zu implementieren, getrennt von Basis-API und Transaktions-API.

Postman Public collection
Zahlungs-SplitRegeln für den Zahlungs-Split
Ausgabenmanagement & Firmenkarten

Unternehmenskontrolle, verbunden mit der Plattform.

Ein eigener Bereich für Ausgabe und Verwaltung von Firmenkarten, Festlegung von Limits, Nutzungsrichtlinien, Karteninhabern und Verfolgung der Ausgaben.

CorporateFirmenkarten
CARDAusgabe und Verwaltung pro UnternehmenKarten
RULELimits und NutzungsrichtlinienKontrolle
TEAMKarteninhaber und KostenstellenTeam
VIEWkonsolidierte AusgabenübersichtBetrieb
Quickstart

Vom ersten Request
zur ersten Zahlungsanforderung.In drei Schritten.

Richten Sie die Authentifizierung ein, erstellen Sie den Customer und erzeugen Sie eine Pix-Zahlung mit demselben Ablauf, den Ihre Anwendung in die Produktion bringt.

Schritt01von 03 ·Requests authentifizieren
Schritt 01 · Zugang

Requests authentifizieren

Jede Integration beginnt mit der Authentifizierung Ihrer Zugangsdaten, um das Zugriffstoken für die API zu erhalten.

Bearer TokenTransaction3600s
Was in diesem Schritt zu tun ist
  • E-Mail, Secret und io_seller_id senden.
  • Das access_token empfangen.
  • Das Bearer Token in den nächsten Requests verwenden.
Diesen Schritt verstehen
Ziel
Ihre Anwendung kommuniziert authentifiziert mit der IOPAY-API.
Erwartete Antwort
Ein Zugriffstoken zur Authentifizierung der nächsten Requests.
Wo es ansetzt
Zu Beginn der Integration, vor dem Zugriff auf Customers, Karten oder Transaktionen.
Authentifizierungsbeispiel
Docs ↗

        
Beispielantwort · JSON
Nächster Schritt

Mit fertiger Authentifizierung ist der nächste Schritt, den Käufer anzulegen, der die Zahlungsanforderung erhält.





Zahlungsarten

Eine Integration.Jede Zahlung,
ihr eigener Ablauf.

Pix, Karte und Boleto leben im Transaktionskern. Zahlungslinks bringen dieselbe Infrastruktur zu betreuten Verkäufen, Fernzahlungen und Kanälen ohne eigenen Checkout.

PIX

Pix

Erstellung von Sofortzahlungen, QR-Code und Verfolgung der Bestätigung per Ereignis.

Ideal für Checkout, Fernzahlungen und Sofortzahlungsabläufe.
CC

Karten

Kredit als Einmal- oder Ratenzahlung, Tokenisierung und Abläufe für Wiederkauf oder wiederkehrende Zahlungen.

Ermöglicht die Kombination eines eigenen Checkouts mit den Autorisierungsabläufen des Betriebs.
BLT

Boleto

Ausstellung und Verfolgung von Zahlungsanforderungen für Abläufe, die eine Zahlung per Zahlschein erfordern.

Der Status der Zahlungsanforderung kann in die internen Prozesse des Unternehmens integriert werden.
LNK

Zahlungslinks

Erstellen Sie gehostete, teilbare Zahlungsanforderungen per API, um außerhalb des klassischen Checkouts zu verkaufen.

CRM, WhatsApp, Inside Sales, Kundenservice und betreute Abläufe.


Webhooks & Ereignisse

Ihr System muss nicht nachfragen.
Iopay meldet sich in Sekunden.

HTTP POST Echtzeit Kein Polling

IOPAY empfängt die Zahlungsaktualisierung, verarbeitet den neuen Status und sendet den Webhook an Ihren Endpunkt. Wenig Reibung, klarer Ablauf und synchronisierte Systeme.

Setzen Sie auf die resiliente Webhook- und Ereignisschicht von Iopay mit automatischer erneuter Zustellung, wenn Ihr Server nicht erreichbar ist.

01 · Ursprung Die Zahlung ändert sich.

Neuer Status in der Infrastruktur.

→→→→→→→→→→→→→→
03 · Ihr System Der Webhook kommt an. Immer.

Ihr Endpunkt empfängt den POST-Request von Iopay, und Sie verarbeiten und reagieren, wie Sie möchten. Ihr System handelt, nachdem eine Zahlung erstellt, genehmigt, fehlgeschlagen, erstattet oder teilweise storniert wurde. Mit der Bestätigung hat Ihr System alles, um die Bestellung freizugeben, CRM und ERPs zu speisen, mit SAP zu interagieren sowie Fulfillment und Rechnungsstellung zu integrieren.

SDKs IOPAY

SDKs für Java, Javascript, Node.js und
PHP / Laravel.

Nutzen Sie die öffentlichen IOPAY-Clients in Node.js und PHP / Laravel oder integrieren Sie direkt über die REST-API in jeder Sprache. Weniger Boilerplate zum Start, ohne den Zugang zum HTTP-Vertrag der Plattform zu verlieren.

Offizielles SDK · Node.js

Fertige Integration für JavaScript-Anwendungen.

Öffentlicher Client mit Authentifizierung, Umgebungen, Tokenisierung, Customers und den wichtigsten Transaktionsvorgängen.

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

// depois, use o client IOPAY no projeto
Offizielles SDK · PHP

Composer für PHP- oder Laravel-Projekte.

Das offizielle Paket iopay-payments/sdk-php kann über Composer installiert und über den Autoload des Projekts genutzt werden, auch in Laravel-Anwendungen.

Installation über Composer
composer require
iopay-payments/sdk-php

// disponível no vendor/autoload.php do projeto
REST-API · jeder Stack

Nutzen Sie direktes HTTP, wenn Sie volle Kontrolle wollen.

Python, Go, Java, .NET, Ruby oder jeder andere Stack kann die IOPAY-API direkt über HTTPS nutzen, mit denselben veröffentlichten Endpunkten und Verträgen.

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

Integration und Betrieb müssen dieselbe Sprache sprechen.

Nach dem Deployment müssen Engineering, Produkt, Finanzen und Kundenservice dieselbe Zahlung sehen. Das IOPAY-Portal ergänzt die API um Transaktionsansicht, Forderungen, Zugangsdaten, Berichte und operative Verfolgung.

01Transaktionen Fragen Sie Status, Kunde, Methode, Betrag und Referenzen des Betriebs ab.
02Forderungen Verfolgen Sie die Finanzansicht zu den verarbeiteten Verkäufen.
03Zugangsdaten Zentralisieren Sie die für die Integrationsumgebungen nötigen Daten.
04Berichte Unterstützen Sie Betriebs- und Abstimmungsroutinen, ohne nur vom Engineering-Team abhängig zu sein.
IOPAY-BetriebKonsolidierte Ansicht
TRANSAKTIONEN883
GENEHMIGUNG60,4%
TPVR$ 2,58 Mio.
TransaktionMethodeStatusBetrag
0b527...9a6creditGenehmigtR$ 1.002
44d23...9044pixAusstehendR$ 3.482
34fad...29e7creditGenehmigtR$ 5.444
Sicherheit & Architektur als Kern und Gründungsprinzip

APIs und Architektur, gemacht für den Betrieb von
Zahlungen mit Kontrolle, Sicherheit und Überblick.

Zugangsdaten, Trennung der Umgebungen, Tokenisierung und Sicherheitskontrollen sind Teil der Produktarchitektur und verringern die unnötige Offenlegung sensibler Daten.

01Getrennte Zugangsdaten

Trennen Sie Entwicklung, Tests und Produktion mit passenden Zugangsdaten für jede Umgebung.

02Tokenisierung

Verringern Sie den Umlauf sensibler Daten bei Wiederkauf, wiederkehrenden Zahlungen und One-Click.

03PCI DSS 4.0.1

Sicherheitskontrollen und Schutz der Zahlungsumgebung, angewandt auf die IOPAY-Infrastruktur.

04Ereignisse und Nachverfolgbarkeit

Nutzen Sie Kennungen, Status und Webhooks, um den Transaktionszyklus zu verfolgen und auf Ausnahmen zu reagieren.

Anwendungsfälle

Architektur für unterschiedliche
Geschäftsmodelle.

Die IOPAY Developer Platform wurde für Produkte entwickelt, die Zahlungen in ihr eigenes Erlebnis einbetten müssen, vom E-Commerce über SaaS, Marketplace und ERP bis zum betreuten Verkauf.

E-Commerce

Eigener Checkout.

Steuern Sie das Käufererlebnis, während IOPAY die Zahlungs- und Ereignisschicht ausführt.

E-Commerce ansehen →
SaaS & wiederkehrende Zahlungen

Wiederkauf und fortlaufende Abrechnung.

Kombinieren Sie Tokenisierung, Customers, Ereignisse und die Logik Ihrer Anwendung für wiederkehrende Abläufe.

Dokumentation ansehen →
Marketplaces

Seller und Zahlungs-Split.

Bringen Sie den Kontext der Seller und die Regeln des Zahlungs-Splits in den Transaktionsablauf.

Marketplaces ansehen →
ERP & Finanzen

Mit dem Betrieb verbundene Zahlungen.

Integrieren Sie Zahlungsanforderungen und Ereignisse in interne Prozesse für Abstimmung, Service und Finanzen.

Mit Experten sprechen →
Inside Sales

Zahlung im Funnel.

Erzeugen Sie Links oder Transaktionen aus dem CRM und geben Sie den Status an Vertrieb, Onboarding und Finanzen zurück.

Links ansehen →
White-Label

Infrastruktur unter Ihrem Erlebnis.

Kombinieren Sie APIs und Plattformressourcen, um in Ihre Marke integrierte Zahlungsabläufe anzubieten.

White-Label ansehen →
IO-Integration und APIs

Vom ersten Aufruf bis zur Produktion. Setzen Sie auf die beste Architektur für Zahlungslösungen

Erkunden Sie die Dokumentation, testen Sie Ihre Integration und bringen Sie Zahlungen mit der IOPAY-Infrastruktur in Ihr Produkt.