Accepter un paiement

Le flux

1. Le client clique sur payer ; vous ouvrez le checkout.
2. Le SDK crée le paiement et affiche les chaînes et tokens disponibles.
3. Le client connecte un wallet et passe sur la bonne chaîne.
4. Le SDK vérifie le solde avant de le laisser envoyer.
5. Le client signe ; onSuccess se déclenche.
6. Votre serveur confirme le paiement et honore la commande.

Les étapes 2 à 5 sont le travail du SDK. L’étape 6 est le vôtre, et c’est celle que l’on oublie.

Pourquoi l’étape 6 n’est pas facultative

onSuccess signifie que le wallet a accepté la transaction et l’a diffusée. Cela ne signifie pas que les fonds sont arrivés. La transaction peut échouer, être remplacée par une autre avec des frais plus élevés, ou être abandonnée par la mempool.

C’est aussi un événement côté client : n’importe qui pouvant ouvrir la console du navigateur sur votre page de paiement peut le déclencher. Une commande honorée sur décision du navigateur est une commande que n’importe qui peut obtenir.

onSuccess={(paymentId, txHash) => {
  // Right: hand it to your server and let the server decide.
  fetch('/api/orders/awaiting-confirmation', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ paymentId, txHash }),
  });

  // Wrong: fulfilling here trusts the browser.
  // grantAccess();
}}

Confirmez ensuite côté serveur, soit par webhook, soit en lisant le statut avec votre clé.

Vérification des soldes

Avant d’autoriser l’envoi, le SDK vérifie que le client dispose de suffisamment du token, et de suffisamment de monnaie native pour le gas. Cela détecte l’échec le plus courant, avoir des USDC mais pas d’ETH pour le gas, avant toute tentative de transaction, plutôt qu’après un revert.

Montants qui ne correspondent pas

Un client peut envoyer plus ou moins que le montant facturé. Aucun des deux cas ne casse le paiement, et chacun a un traitement défini : consultez Paiements excédentaires et remboursements.