---
title: Page de paiement
description: Page de paiement Coinetic hébergée : ce que voit le client, comment l'ouvrir sur un site ou une app mobile et le rediriger vers votre boutique.
url: https://coinetic.money/fr/docs/checkout/
lang: fr
---

# Page de paiement

La page de paiement, c'est nous qui la fournissons. Votre serveur se contente d'y rediriger le client, via le `checkout_url` renvoyé à la création de la facture.

## Ce que voit le client

- Le montant de la commande et le compte à rebours de validité de la facture.
- Le choix de la devise : uniquement les actifs de la facture disponibles à cet instant.
- Une fois la devise choisie : un QR code, le montant exact avec un bouton « Copier », l'adresse, un avertissement sur le réseau et un lien « Ouvrir dans le portefeuille » (BIP21, EIP-681, Solana Pay, TRON).
- Un statut qui se met à jour tout seul : « Paiement détecté » → « Confirmations 7/20 » → « Paiement reçu ».
- Un bouton « Retour à la boutique » qui mène à votre `return_url`.

Tant que rien n'est payé, le client peut changer de devise. Dès le premier paiement, la devise est figée. Pour un actif volatil, un minuteur de cours tourne (20 minutes) ; à son expiration, le montant et l'adresse sont masqués.

La page est disponible en russe et en anglais, en thème clair ou sombre selon les réglages de l'appareil.

## Comment l'ouvrir

| Où | Comment |
| --- | --- |
| Site web | Navigation dans le même onglet : `303 See Other` depuis votre serveur ou `location.href` |
| iOS | `ASWebAuthenticationSession` ou `SFSafariViewController` |
| Android | Chrome Custom Tabs (`androidx.browser`) |
| Bot Telegram | Bouton inline avec un lien vers `checkout_url` |
| **À proscrire** | `iframe`, `WKWebView`, `WebView` : pas de barre d'adresse (impossible de distinguer un site de phishing), liens vers les portefeuilles peu fiables. La page interdit d'ailleurs l'intégration (`frame-ancestors 'none'`) |

> **Applications mobiles.** L'application n'appelle jamais l'API Coinetic directement et ne stocke pas le secret de la clé : on l'extrait d'un build en quelques minutes. C'est votre serveur qui crée la facture à la demande de l'application, et il ne lui renvoie que le `checkout_url`.

## Retour du client

- Le client peut revenir avant de payer, pendant les confirmations, ou ne jamais revenir. Votre page de commande ne doit pas en dépendre.
- Vous pouvez passer le numéro de commande dans le `return_url`, mais **lisez le statut dans votre propre base** : c'est le webhook qui la met à jour. Si la commande n'est pas encore payée, revérifiez avec `GET /v1/invoices/{id}`.
- Pour une application, passez un lien universel (Universal Links / App Links) : `https://shop.example/app/orders/ORDER-1001`. Les schémas personnalisés (`myapp://`) ne sont pas acceptés.

## Cas fréquents

| Situation | Que faire |
| --- | --- |
| Le client a fermé l'onglet | Affichez dans la commande un lien « Procéder au paiement » vers `checkout_url` : la facture reste valable jusqu'à `expires_at` |
| La facture a expiré | Créez une nouvelle facture avec un nouvel `order_id` (par exemple `ORDER-1001-2`) et un nouvel `Idempotency-Key` |
| Sous-paiement | « Payez le solde à la même adresse » : la page de paiement affiche le reste dû |
| Paiement après expiration | Les fonds sont reçus, la décision vous appartient : livrer la commande ou effectuer un remboursement |
| Contrôle AML | Indiquez au client que le paiement est en cours de vérification ; attendez `invoice.paid` |