Configuration des paiements — et l'étape qui fait silencieusement perdre de l'argent — Documentation

Les identifiants de paiement sont côté serveur uniquement : ils vivent sur votre machine et jamais dans la base de données, jamais affichés dans un formulaire. C'est délibéré. Ce qui suit indique où va chaque valeur — et l'étape facile à manquer et coûteuse à manquer.

L'étape qui coûte de l'argent si vous la sautez

La plupart des moyens de paiement indonésiens sont asynchrones. Un acheteur choisit un compte virtuel, un portefeuille électronique, ou paie dans un point de vente, puis ferme l'onglet. Il peut terminer de payer une heure plus tard, depuis son application bancaire, sur un autre appareil. Rien de tout cela ne revient jamais à votre site web.

Ainsi, l'achat est finalisé par le fournisseur appelant votre serveur — un webhook — et par rien d'autre.

Si cet appel n'arrive jamais :

l'argent de l'acheteur vous parvient,
sa licence n'est jamais émise,
la commande reste à « en attente »,
et rien nulle part n'en dit la raison.

Ce n'est pas un cas limite rare. Sur les moyens de paiement indonésiens, c'est le parcours normal.

Où chaque fournisseur obtient son URL

Fournisseur	URL du webhook	Qui la définit
Xendit	`https://yourdomain/webhooks/xendit`	vous, à la main, une fois
PayPal	(aucune)	inutile — il se finalise au retour

PayPal se finalise au retour de l'acheteur, il n'a donc besoin d'aucun webhook. Xendit est celui qui a besoin de vous — voir ci-dessous.

Xendit est celui qui a besoin de vous. Son rappel « facture payée » vaut pour tout le compte, pas par facture, il se définit donc une seule fois dans le tableau de bord propre à Xendit.

Xendit, clic par clic

Connectez-vous sur dashboard.xendit.co.
Settings → Developers → Webhooks.
Sous Invoices paid, collez l'URL que votre page admin affiche pour Xendit (https://yourdomain/webhooks/xendit).
Enregistrez, et copiez le webhook verification token affiché sur la même page.
Placez ce jeton dans le .env de votre serveur sous XENDIT_CALLBACK_TOKEN, aux côtés de XENDIT_SECRET_KEY.
Redémarrez le site pour que les nouvelles valeurs soient lues.

Les deux moitiés sont requises. L'URL sans le jeton signifie que les livraisons arrivent et sont refusées ; le jeton sans l'URL signifie que rien n'arrive du tout.

Prouver que cela fonctionne réellement

Ne vous fiez pas à « je l'ai collée ». Ouvrez Admin → Settings → Payment webhooks. Elle rapporte ce qui a véritablement atteint votre serveur :

Ce qu'elle affiche	Ce que cela signifie	Que faire
Never received	Rien n'est jamais arrivé de ce fournisseur	L'URL est manquante ou incorrecte dans le tableau de bord du fournisseur
Not matching	Des livraisons arrivent mais ne nomment aucune de vos commandes	L'URL pointe vers vous depuis un compte fournisseur différent de celui que la boutique utilise
Working	Au moins une livraison a correspondu à une vraie commande	Rien — c'est bien câblé

Les compteurs ne bougent que pour les appels qui portent les identifiants propres au fournisseur, ainsi une sonde aléatoire venue d'internet ne peut jamais faire passer une passerelle non configurée pour saine.

Testez-le de bout en bout avant d'encaisser de l'argent réel. Le tableau de bord de Xendit a un bouton « test webhook » sur la même page ; utilisez-le, puis rechargez la carte admin. S'il indique toujours Never received, l'URL est incorrecte — cherchez une faute de frappe, un https:// manquant, ou une barre oblique finale.

Les identifiants eux-mêmes

Il y a deux façons de les définir. Les deux gardent le secret hors de vue — aucune n'affiche jamais une valeur enregistrée.

Depuis la page admin (recommandé)

Admin → Settings → Payment gateway credentials. Saisissez le Client ID + Secret PayPal (et le commutateur sandbox/live) ainsi que la Secret Key + le Callback token Xendit. Ils sont stockés chiffrés sur le serveur ; les champs sont en écriture seule, si bien qu'une fois enregistrés ils ne sont plus jamais affichés — la page indique seulement Configured / Not set. Laissez un champ vide pour le conserver inchangé ; utilisez Remove stored credentials pour en effacer un.

Configuration unique : générez la clé qui les chiffre, gardée séparée de la clé de l'application afin qu'un vidage de base de données et une fuite du .env soient chacun inutiles à eux seuls :

php artisan store:secrets-key      # writes STORE_SECRETS_KEY to .env — then BACK IT UP off the server
php artisan config:clear

Perdre STORE_SECRETS_KEY rend les identifiants stockés illisibles (vous n'auriez qu'à les ressaisir).

Ou depuis `.env` (alternative)

Si vous préférez, définissez-les plutôt dans le .env du serveur, puis redémarrez. Les valeurs de la page admin priment lorsque les deux sont présentes.

# Xendit
XENDIT_SECRET_KEY=...
XENDIT_CALLBACK_TOKEN=...     # from Settings → Developers → Webhooks

# PayPal
PAYPAL_CLIENT_ID=...
PAYPAL_SECRET=...
PAYPAL_ENV=sandbox           # or: live

Une passerelle sans identifiants est simplement désactivée — il n'y a rien d'autre à activer.

Si votre serveur est derrière un proxy ou un pare-feu

Le chemin du webhook est une URL publique, de serveur à serveur. Il n'a pas de connexion, par nécessité — le fournisseur ne peut pas se connecter en votre nom. Il est protégé à la place par la signature ou le jeton propre au fournisseur, par une relecture autoritaire du statut de paiement directement depuis le fournisseur, et par une limite de débit.

Cela signifie que POST /webhooks/* doit être joignable depuis l'internet public. Si vous le bloquez, ou si vous placez tout le site derrière une liste d'autorisation d'IP, les paiements asynchrones cessent d'être honorés — avec exactement le même symptôme silencieux que si l'URL n'avait jamais été configurée.

Configuration des paiements — et l'étape qui fait silencieusement perdre de l'argent