Binance Smart Chain API per pagamenti BNB e BEP-20
Invia e ricevi BNB e token BEP-20 con un'unica API REST. Crea indirizzi di deposito, ricevi webhook firmati HMAC, e vai live su BSC senza gestire un node.
La Binance Smart Chain API di Chaingateway sposta BNB e token BEP-20 tramite semplici chiamate REST. Il tuo backend crea indirizzi di deposito su HTTPS e invia token con una singola richiesta POST. Quando un cliente paga, un webhook raggiunge il tuo server, sincronizzato con i blocchi sub-secondo di BSC. Non c'è alcun nodo da gestire né alcuna libreria web3 da installare: l'autenticazione è un Bearer token nell'header Authorization, e ogni risposta è JSON.
La registrazione richiede un minuto. La prova dura 7 giorni, non costa nulla e non richiede KYC. Crea una API key e invia oggi stesso la tua prima transazione testnet.
Tutto ciò che ti serve per costruire su Binance Smart Chain
Webhook (IPN)
BSC ha prodotto un blocco circa ogni 0,75 secondi da quando l'hardfork Maxwell è entrato in vigore il 30 giugno 2025, e le notifiche di deposito seguono lo stesso ritmo. Quando un trasferimento BEP-20 raggiunge uno dei tuoi indirizzi, Chaingateway chiama il tuo endpoint con il payload decodificato. Imposta un secret personale nel tuo profilo e ogni chiamata porterà un header X-Signature così puoi verificare il mittente. Se il tuo endpoint era offline, le consegne fallite sono elencate dall'API e reinviabili con una chiamata per notifica.
Transazioni semplici
Una richiesta POST invia BNB (POST /api/v2/bsc/transactions) o qualsiasi token BEP-20 (POST /api/v2/bsc/transactions/bep20). Gas e nonce sono campi opzionali della richiesta che l'API compila, quindi non regoli mai a mano valori in gwei né tracci nonce tra payout concorrenti.
Gestione sicura degli indirizzi
BSC usa lo stesso formato di indirizzo 0x e lo stesso checksum EIP-55 di Ethereum. L'API valida ogni indirizzo prima di costruire una transazione, e l'architettura è non-custodial: le tue key restano tue. Se già gestisci coppie di chiavi, registrale con POST /api/v2/bsc/addresses/import.
Query decodificate
I log grezzi di BSC sono blob esadecimali. L'endpoint di transazione decodificata di Chaingateway restituisce invece JSON leggibile — mittente, destinatario e importo come campi semplici — e i payload dei webhook arrivano decodificati allo stesso modo.
Una API REST, non un altro endpoint RPC
Se hai cercato "Binance Smart Chain RPC", probabilmente ti aspettavi un URL di nodo. La documentazione ufficiale su docs.bnbchain.org elenca endpoint JSON-RPC pubblici, e funzionano. Ma lasciano a te la parte difficile. Una connessione RPC grezza comprende eth_call e eth_sendRawTransaction; la codifica ABI e la gestione del nonce avvengono nel tuo codice, così come la gestione delle key. Gli endpoint pubblici inoltre limitano aggressivamente sotto carico, esattamente quando il tuo sistema di pagamento ne ha più bisogno.
Chaingateway si posiziona un livello più in alto. Dici all'API quale token inviare, quanto e a chi. Lei costruisce la transazione e la trasmette alla rete; ogni transazione creata tramite l'API viene elencata, hash incluso, sotto GET /api/v2/bsc/transactions, così puoi collegare i tuoi utenti direttamente a BscScan.
Il compromesso è onesto: se ti servono chiamate a contratto arbitrarie o query di profondità archive, gestisci un nodo o usa un provider RPC. Se ti servono pagamenti, cioè depositi in entrata e payout in uscita, il livello REST rimuove la maggior parte del codice che altrimenti dovresti scrivere e mantenere da solo.
Riferimento endpoint BSC
La documentazione ufficiale BNB Chain risponde alla domanda RPC con un elenco di quindici metodi JSON-RPC e un URL di nodo pubblico. Quell'elenco descrive il protocollo. Un'integrazione di pagamento ha bisogno di qualcosa di più breve. Cinque endpoint coprono l'intero ciclo su Chaingateway:
| Metodo | Endpoint | Cosa fa |
|---|---|---|
POST | /api/v2/bsc/addresses/import | Registra una private key esistente perché l'API possa inviare da quell'indirizzo |
POST | /api/v2/bsc/transactions | Costruisce, firma e trasmette un trasferimento nativo di BNB |
POST | /api/v2/bsc/transactions/bep20 | Costruisce, firma e trasmette un trasferimento di token BEP-20 |
GET | /api/v2/bsc/webhooks/notifications | Elenca ogni notifica di deposito inviata dall'API al tuo server |
GET | /api/account | Controlla lo stato del tuo account e piano |
Ciascuno di essi accetta l'header X-Network: testnet per le prove, e ogni richiesta si autentica con lo stesso Bearer token. Gli schemi esatti di richiesta e risposta sono nella documentazione API.
Metodo JSON-RPC contro una singola chiamata REST
Ecco la stessa tabella dal lato dell'integratore: cosa ti costa un compito contro un nodo grezzo, e cosa ti costa contro il livello REST.
| Compito da svolgere | JSON-RPC grezzo | Chaingateway |
|---|---|---|
| Inviare 25 USDT | eth_gasPrice, eth_getTransactionCount, eth_estimateGas, eth_sendRawTransaction, più codifica ABI e firma della transazione nel tuo codice |
Una POST /api/v2/bsc/transactions/bep20 |
| Rilevare un deposito | Fare polling su eth_blockNumber, scansionare eth_getLogs per eventi Transfer, decodificare i topic e correggere per i decimali del token |
Arriva una POST del webhook al tuo server |
| Verificare la cronologia dei depositi | Costruire e gestire il proprio indexer | GET /api/v2/bsc/webhooks/notifications |
Per farti un'idea della differenza, ecco come appare parlare con un nodo pubblico BSC:
curl -X POST https://bsc-dataseed.bnbchain.org \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
La risposta è una stringa esadecimale. Tutto ciò che viene dopo, dal convertire 0x30bf8d3 in un numero al recuperare log e mappare importi grezzi contro i decimali del token, è codice che scrivi e debugghi tu. Moltiplica ciò per ogni metodo di cui hai bisogno e finisci con un piccolo progetto di middleware interno. La chiamata REST salta il middleware perché è essa stessa il middleware.
BSC in numeri
BSC ha puntato a blocchi da 0,75 secondi dall'hardfork Maxwell del 30 giugno 2025, e il gas è rimasto economico, tipicamente 0,1-1 gwei sul tracker di BscScan. Un trasferimento BEP-20 standard consuma 50.000-65.000 di gas, il che a quei prezzi equivale a una frazione di centesimo.
I dati della chain invecchiano rapidamente, quindi ecco le cifre complete con date associate. Ai primi di luglio 2026:
L'intervallo di blocco target è 0,75 secondi. L'hardfork Maxwell lo ha fissato il 30 giugno 2025, e BscScan ha misurato una media di circa 0,8 secondi poco dopo l'attivazione. In precedenza nel 2025 l'hardfork Lorentz aveva già dimezzato il vecchio intervallo di 3 secondi a 1,5 secondi, quindi BSC ha ridotto il proprio block time di un quarto in un solo anno.
Il gas è economico ed è rimasto tale. Il gas tracker di BscScan ha oscillato nell'intervallo 0,1-1 gwei per tutto il 2026, con una media giornaliera intorno a 0,63 gwei a marzo 2026. Un trasferimento BEP-20 standard consuma nell'ordine di 50.000-65.000 di gas, che a quei prezzi equivale a circa 0,00004 BNB. Verifica tu stesso il prezzo attuale di BNB prima di quotare commissioni ai clienti, ma il risultato si è mantenuto sui pochi centesimi per anni.
Per una pagina di checkout la conseguenza pratica è questa: il trasferimento USDT di un cliente è in un blocco entro circa un secondo, e dopo qualche blocco aggiuntivo, pochi secondi in totale, puoi accreditare l'ordine. Confrontalo con Ethereum mainnet, dove il solo slot richiede già 12 secondi.
Invia e ricevi qualsiasi token su BSC, anche il tuo
Ogni contratto BEP-20 standard funziona. USDT, USDC e DAI funzionano immediatamente, con importi in unità di token anziché unità base grezze. Se hai lanciato un tuo token, passa il suo contract address allo stesso endpoint e si comporterà come qualsiasi altro. Poiché l'API è identica tra le chain, il codice che scrivi per BSC gira anche contro Ethereum, Polygon o Arbitrum una volta scambiato il segmento chain nell'URL.
Perché gli sviluppatori scelgono Binance Smart Chain
Le commissioni su BSC restano molto al di sotto di Ethereum mainnet, il che conta quando elabori molti piccoli pagamenti anziché pochi grandi. I block time sub-secondo mantengono i flussi di checkout scattanti. L'ecosistema DeFi attorno a PancakeSwap dà ai token BEP-20 una liquidità profonda, e la rete ha sostenuto un uso giornaliero attivo elevato per anni, quindi le sue modalità di errore sono ben comprese e i suoi strumenti sono maturi.
Quickstart: invia USDT (BEP-20) in quattro linguaggi
Tutti gli esempi chiamano POST /api/v2/bsc/transactions/bep20 con un Bearer token. Il contract address sotto è quello di USDT su BSC (0x55d398326f99059fF775485246999027B3197955); password è la password del wallet protetto dell'indirizzo mittente. Lo schema esatto della richiesta è nella documentazione API. Per testare senza fondi reali, aggiungi l'header X-Network: testnet.
cURL
curl -X POST https://app.chaingateway.io/api/v2/bsc/transactions/bep20 \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"contractaddress": "0x55d398326f99059fF775485246999027B3197955",
"from": "0xYourSenderAddress",
"to": "0xRecipientAddress",
"amount": 25.0,
"password": "wallet-password"
}'Questa è l'intera richiesta di trasferimento — crea un account ed eseguila prima sulla testnet BSC.
Come i depositi BEP-20 raggiungono il tuo backend
Un'integrazione di pagamento su BSC segue un ciclo:
- Dai a ogni utente un indirizzo di deposito. Se il tuo sistema già gestisce le key, registrale con
POST /api/v2/bsc/addresses/import. - Collega un webhook all'indirizzo. La configurazione richiede pochi minuti ed è descritta nella guida ai webhook.
- Il cliente invia USDT all'indirizzo. Il trasferimento finisce in un blocco entro circa un secondo, e Chaingateway invia tramite POST l'evento decodificato al tuo endpoint.
- Il tuo server verifica la firma HMAC e accredita l'account. Questo è l'intero flusso.
In produzione, tre dettagli separano una demo da un sistema che puoi lasciare in pace.
Il primo è la mappatura degli indirizzi. Memorizza una riga per cliente o per ordine: il tuo ID interno, l'indirizzo di deposito, la data di creazione. Quando arriva un webhook, l'indirizzo destinatario nel payload è la tua chiave di ricerca. Un indice univoco sulla colonna indirizzo garantisce che un deposito non possa mai essere accreditato a due clienti, indipendentemente da come cambia il codice attorno.
Il secondo è l'idempotenza. La consegna non è esattamente-una-volta: una notifica fallita che reinvii tramite l'API arriva di nuovo per intero. Registra l'hash di transazione di ogni deposito elaborato con un vincolo univoco, e lascia che il database rifiuti i duplicati. Una logica di accredito che sopravvive allo stesso evento arrivato tre volte è la differenza tra un meccanismo di reinvio che ti protegge e uno che paga doppio.
Il terzo è una policy di conferma. Un webhook ti dice che il trasferimento è in un blocco. Con blocchi da 0,75 secondi, altri dieci blocchi arrivano in ben meno di dieci secondi, quindi attendere un piccolo margine di sicurezza costa quasi nulla in termini di user experience. Per un acquisto digitale da 5 USDT, accreditare sulla notifica è una decisione di business ragionevole. Per un deposito da 50.000 USDT, attendi qualche secondo in più e ricontrolla la transazione (GET /api/v2/bsc/transactions/{txid}) prima di rilasciare qualsiasi cosa.
I depositi si accumulano anche su molti indirizzi nel tempo. La risposta abituale è un consolidamento periodico: un job programmato che invia i saldi accumulati dagli indirizzi di deposito al tuo wallet di tesoreria, usando la stessa chiamata POST /api/v2/bsc/transactions/bep20 con l'indirizzo di deposito nel campo from. Ogni indirizzo che consolida necessita di una briciola di BNB per il gas, che a prezzi sub-gwei è un errore di arrotondamento.
Se il tuo endpoint era irraggiungibile, le consegne mancate non sono perse: GET /api/v2/bsc/webhooks/notifications/failed le elenca, e POST /api/v2/bsc/webhooks/notifications/{id}/retry reinvia ciascuna. Per la riconciliazione, puoi anche elencare tutto ciò che l'API ti ha inviato:
curl https://app.chaingateway.io/api/v2/bsc/webhooks/notifications \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY"
Quell'unico endpoint trasforma "ci siamo persi un deposito?" da un ticket di supporto a un confronto con il tuo database.
Payout: l'altra metà del ciclo
I prelievi meritano la stessa cura dei depositi, perché un bug qui invia denaro anziché perderlo.
Valida prima di inviare
Il flusso inizia prima della chiamata API. Valida l'indirizzo di destinazione nel momento in cui l'utente lo invia: lunghezza corretta, prefisso 0x, e il checksum EIP-55 se sono presenti lettere maiuscole e minuscole miste. Un fallimento del checksum significa un errore di battitura, e coglierlo nel form non costa nulla, mentre coglierlo dopo la trasmissione è impossibile. L'API rifiuta indirizzi malformati prima di costruire la transazione, ma il test del checksum spetta a te eseguirlo — e nel momento in cui l'API risponde, l'utente ha già lasciato la pagina.
Traccia ogni payout nel tuo database
Scrivi il payout nel tuo database prima di inviarlo. Una riga per payout, con una colonna di stato: queued, sent, confirmed. Un worker preleva le righe in coda, effettua esattamente una chiamata POST /api/v2/bsc/transactions/bep20 per riga, e memorizza la risposta dell'API accanto ad essa. L'hash di transazione — la tua ricevuta — compare in GET /api/v2/bsc/transactions, l'elenco di tutto ciò che è stato creato tramite l'API. Mostralo all'utente come un link BscScan e potrà vedere il proprio prelievo confermarsi, il che elimina silenziosamente il ticket di supporto più comune di questa categoria.
Gestione dei timeout
Il caso di errore che conta è il timeout. Se la tua chiamata API va in timeout, non sai se il trasferimento è uscito. Non ritentare alla cieca. Controlla prima GET /api/v2/bsc/transactions e i tuoi record, e reinvia solo quando sei sicuro che nulla sia stato trasmesso. Poiché i payout partono da un hot wallet, mantieni una riserva di BNB sull'indirizzo mittente per il gas; ai prezzi attuali di BSC una piccola ricarica copre migliaia di trasferimenti, quindi è un compito mensile piuttosto che un rischio operativo.
Testa prima sulla testnet BSC
Ogni endpoint di questa pagina gira contro la testnet BSC quando aggiungi un header:
X-Network: testnet
Nessun secondo account, nessuna API key separata, nessuna modifica di codice oltre all'header. Il BNB testnet arriva gratis dal faucet ufficiale BNB Chain, così puoi provare l'intero ciclo, dalla creazione dell'indirizzo al webhook di deposito fino al payout, senza fondi reali. Formati degli indirizzi e meccanica delle transazioni sono identici a mainnet.
La prova che vale la pena fare è quella scomoda: invia un deposito mentre il tuo endpoint webhook è spento, riportalo su, poi reinvia la consegna dall'elenco fallite (POST /api/v2/bsc/webhooks/notifications/{id}/retry) e osserva come arriva. Conferma la tua gestione dell'idempotenza riproducendo una notifica verso il tuo stesso endpoint. Dieci minuti di test di fallimento deliberato su testnet risparmiano una revisione di incidente su mainnet. Quando tutto regge, elimina l'header e lo stesso codice è in produzione.
Sicurezza dei webhook in pratica
Un endpoint webhook è una porta verso il tuo sistema contabile, quindi trattalo come tale.
Verifica la firma prima di analizzare qualsiasi altra cosa. Imposta un secret personale nelle impostazioni del tuo profilo; da quel momento Chaingateway invia un header X-Signature con ogni notifica — base64 di un HMAC-SHA256 sul txid del payload, con quel secret come chiave. Il tuo server lo ricalcola dal txid ricevuto e lo confronta a tempo costante. Una richiesta che fallisce il controllo riceve un 4xx e nessuna elaborazione ulteriore, indipendentemente da quanto plausibile appaia il suo payload. La meccanica, codice di verifica incluso, è nella guida ai webhook.
Un secondo lucchetto, separato, protegge l'altra direzione: nel pannello account puoi limitare la tua API key agli indirizzi IP dei tuoi server. Quella whitelist protegge l'accesso API — una key trapelata non sposta nulla da nessun'altra parte — non l'endpoint webhook, quindi completa la firma invece di sostituirla.
Il replay è l'attacco che l'HMAC da solo non ferma, poiché una notifica valida registrata resta valida. Il tuo vincolo di idempotenza chiude quella falla: un hash di transazione già accreditato viene riconosciuto e ignorato. Servi l'endpoint solo via HTTPS, e tieni l'URL del webhook privo di segreti, perché gli URL finiscono nei log di sistemi che non controlli.
Quando le richieste falliscono
Ogni integrazione prima o poi vede errori, e l'API li riporta come normali codici di stato HTTP, quindi i tuoi pattern di gestione errori esistenti si applicano.
Un 401 significa che il Bearer token manca, è scaduto o è sbagliato; controlla l'header Authorization e la key nel tuo pannello. I fallimenti di validazione nell'intervallo 4xx, come un indirizzo malformato o un campo mancante, arrivano con un corpo JSON che spiega cosa correggere. Non ritentare questi: la stessa richiesta fallirà nello stesso modo finché il payload non cambia.
I limiti di richiesta e indirizzo dipendono dal tuo piano; se li incontri regolarmente, la pagina prezzi elenca piani con limiti più alti. Gli errori 5xx lato server e i timeout sono sicuri da ritentare per le richieste di lettura. Per gli invii, applica la regola del timeout della sezione payout: verifica che nulla sia stato trasmesso prima di inviare di nuovo.
Registra il corpo completo della risposta accanto al tuo record di richiesta. Quando qualcosa richiede l'attenzione del supporto, quell'abbinamento risponde alla maggior parte delle domande prima che vengano poste. I codici di stato e gli schemi di errore per ogni endpoint sono documentati nella documentazione API.
Abbandonare il tuo nodo BSC
Molti team gestiscono un full node BSC per un unico scopo: osservare i depositi e trasmettere i payout. Quel nodo costa denaro vero e attenzione. I requisiti di storage si misurano in terabyte di NVMe, la sincronizzazione iniziale richiede giorni senza uno snapshot, e solo il 2025 ha portato due hardfork, Lorentz e Maxwell, ciascuno un aggiornamento client obbligatorio con scadenza. Ne perdi uno e il tuo nodo smette di seguire la chain, il che per un sistema di pagamento significa che i depositi smettono silenziosamente di arrivare.
Se il nodo esiste solo per i pagamenti, il percorso di migrazione è breve. Importa le tue key esistenti con POST /api/v2/bsc/addresses/import, sostituisci il tuo ciclo di polling su eth_getLogs con notifiche webhook, e punta il codice di payout a POST /api/v2/bsc/transactions/bep20. Gestisci entrambi i sistemi in parallelo per una settimana e confronta i risultati; l'elenco delle notifiche trasforma quel confronto in una query invece che in un progetto. Poi dismetti il nodo e recupera il budget hardware.
Se vuoi mantenere un nodo, o stai decidendo se costruirne uno fin dall'inizio, la nostra guida alla configurazione di un nodo Binance Smart Chain illustra onestamente hardware, sincronizzazione e manutenzione. I due approcci si combinano anche: alcuni team mantengono un nodo per query archive e chiamate a contratto instradando il traffico di pagamento tramite l'API, perché il livello webhook dell'API è la parte genuinamente noiosa da ricostruire.
Costruito per ogni caso d'uso
La maggior parte dei team sugli endpoint BSC di Chaingateway esegue uno di due pattern. Il primo è accettare pagamenti: un negozio o SaaS genera un indirizzo di deposito per ordine, attende il webhook e spedisce il prodotto, con liquidazione in secondi invece che giorni bancari. Il secondo sono operazioni wallet su scala: exchange e piattaforme che osservano depositi ed elaborano prelievi su migliaia di indirizzi utente, tutto tramite gli stessi pochi endpoint.
Gli stessi blocchi costruttivi coprono lanci di token (airdrop e payout di vesting scriptati come trasferimenti BEP-20), trasferimenti transfrontalieri dove un bonifico richiederebbe giorni, payout ricorrenti per la fatturazione di abbonamenti, e prodotti DeFi che devono vedere le transazioni nel momento in cui confermano.
Integrazione in tre passaggi
Ottieni la tua API key. Registrati e la key è subito nel tuo pannello. La prova di 7 giorni parte senza KYC.
Fai la tua prima richiesta. Il quickstart ti guida dalla registrazione a una prima transazione.
Configura i webhook e vai in produzione. I depositi arrivano al tuo server invece che tu debba fare polling — la guida ai webhook copre configurazione e verifica della firma — poi rimuovi l'header X-Network: testnet e lo stesso codice gira su mainnet.
Prezzi
Piani e limiti sono elencati nella pagina prezzi. Ogni nuovo account inizia con la prova gratuita di 7 giorni, così puoi completare l'intera integrazione BSC prima di pagare qualsiasi cosa.
Cosa funziona su quale chain
BSC segue lo stesso pattern di richiesta di Ethereum, con BEP-20 al posto di ERC-20. La tabella sotto la colloca accanto alle altre sei chain coperte dall'API.
| Chain | Indirizzi | Trasferimenti di token | Webhook di deposito |
|---|---|---|---|
| Bitcoin | POST /api/v2/bitcoin/wallets/{wallet}/addresses | — (nessuno standard token) | GET /api/v2/bitcoin/webhooks/notifications |
| Ethereum | POST /api/v2/ethereum/addresses/import | ERC-20: POST /api/v2/ethereum/transactions/erc20 | GET /api/v2/ethereum/webhooks/notifications |
| TRON | POST /api/v2/tron/addresses/import | TRC-20 e TRC-10: POST /api/v2/tron/transactions/trc20 e .../trc10 | GET /api/v2/tron/webhooks/notifications |
| Solana | POST /api/v2/solana/addresses | SPL: POST /api/v2/solana/transactions/SPL | — |
| BNB Smart Chain | POST /api/v2/bsc/addresses/import | BEP-20: POST /api/v2/bsc/transactions/bep20 | GET /api/v2/bsc/webhooks/notifications |
| Polygon | POST /api/v2/polygon/addresses/import | ERC-20: POST /api/v2/polygon/transactions/erc20 | GET /api/v2/polygon/webhooks/notifications |
| Arbitrum | POST /api/v2/arbitrum/addresses/import | ERC-20: POST /api/v2/arbitrum/transactions/erc20 | GET /api/v2/arbitrum/webhooks/notifications |
Due note a piè di pagina per leggere correttamente la tabella. Primo: TRON è l'integrazione più profonda della piattaforma. Oltre alle rotte sopra, la documentazione tratta lo staking (POST /api/v2/tron/freeze e /delegate), i parametri di chain, e una coppia di self-signing — /transactions/trc20/build per costruire una transazione e /transactions/broadcast per inviarne una firmata localmente. Se il tuo team compliance insiste che le private key non lascino mai i tuoi server, quel pattern build-and-broadcast è la tua via d'ingresso.
Secondo: un trattino significa che la documentazione attuale non riporta alcuna rotta v2 per quella cella, non che la rete sia di serie B. Bitcoin non ha uno standard token, da cui la cella token vuota — il BTC nativo funziona invece con il proprio modello wallet: crea un wallet protetto da password con POST /api/v2/bitcoin/wallets, deriva indirizzi di deposito sotto di esso, e invia con POST /api/v2/bitcoin/transactions. La documentazione di Solana copre creazione indirizzi, trasferimenti SOL e SPL, e query su saldo e blocco, ma non ancora i webhook. Per qualsiasi cosa non elencata qui, la documentazione API ha lo stato attuale.
Domande frequenti
Pronto a integrare Binance Smart Chain?
Crea il tuo account, copia la API key e invia una transazione testnet nei prossimi dieci minuti. Il riferimento completo degli endpoint è su /docs/, e il portale sviluppatori raccoglie tutorial per i flussi di pagamento più comuni.