Skip to main content
Le SDK PHP alphapay/alphapay-php enveloppe l’API REST AlphaPay (checkout, softpay, liens de paiement, clients, webhooks…) avec retry automatique, gestion d’idempotence et exceptions typées par cas d’erreur. Toutes les ressources marchand sont déjà instanciées sur le client — aucun appel HTTP manuel à écrire. Vous utilisez Laravel ? Préférez le SDK Laravel, qui enveloppe ce package avec une Facade, des Events et un trait Eloquent.

Sommaire

  1. Checkout (session hébergée)
  2. Softpay (encaissement direct)
  3. Lien de paiement
  4. Balance
  5. Clients (CRM)
  6. Webhooks
  7. Reversements et transferts wallet
  8. Clés API et whitelist IP
  9. Gestion des erreurs

1. Checkout (session hébergée)

Une session de checkout génère sa propre page de paiement hébergée (checkout_url) : le client choisit lui-même son réseau et saisit son numéro sur cette page. Contrairement au softpay (section 2), vous n’avez rien à construire côté frontend — juste rediriger le client vers l’URL renvoyée.

2. Softpay (encaissement direct)

Pousse directement une demande de paiement (USSD/mobile money) au numéro du client, sans page de checkout à afficher — utile pour une app mobile ou un parcours de caisse où vous gérez vous-même l’UI. customer exige les 4 champs (email, first_name, last_name, phone) : contrairement à une session de checkout, il n’y a pas de page hébergée où le client les saisirait lui-même après coup.

3. Lien de paiement

Un lien de paiement est réutilisable (contrairement à une session de checkout, one-shot) : sa propre page publique ne nécessite AUCUNE clé API, donc getPublic()/createPublicCheckout() sont les 2 seules méthodes de ce SDK à pouvoir tourner côté client (jamais les autres, qui portent la clé secrète).

4. Balance

Solde disponible par pays/devise. Lecture seule : les mouvements naissent des autres ressources (paiements, reversements, transferts). Le grand livre détaillé (ledgerEntries) est dashboard-only — inaccessible via clé API.

5. Clients (CRM)

Répertoire de clients propre au marchand (distinct de customer passé à payinInitialize/checkoutSessions->create, qui ne fait que remplir une transaction). country ici est un UUID (ForeignKey geo.Country côté API), pas un code ISO2 — contrairement à country sur les paiements/retraits/reversements. Aucune ressource countries dans ce SDK pour résoudre l’UUID : passez par le dashboard ou GET /countries/ via $alphapay->http->request('GET', '/countries/').

6. Webhooks

Créer/gérer un endpoint webhook est dashboard-only (403 via clé API) — seuls list()/get() fonctionnent. En revanche, la vérification de signature d’un webhook reçu est justement ce que ce SDK sert à faire côté serveur marchand.

7. Reversements et transferts wallet

settlements (reversement vers un compte bancaire/mobile money enregistré) et walletTransfers (entre wallets multi-pays d’un même marchand) sont entièrement inaccessibles via clé API, y compris en lecture (403, dashboard_only, vérifié en conditions réelles) — restriction volontaire côté API : ces mouvements ne peuvent être déclenchés/consultés que depuis un compte utilisateur connecté au dashboard. Ce SDK garde ces méthodes pour documenter la forme réelle des endpoints, pas pour un usage effectif ici.

8. Clés API et whitelist IP

Comme les webhooks, créer/lister/révoquer une clé API est dashboard-only (une clé compromise ne doit pas pouvoir en créer d’autres pour elle-même). Seule la whitelist IP (requise pour les payouts) fonctionne via clé API.

9. Gestion des erreurs

Toute erreur API se normalise en une sous-classe d’AlphaPayException — jamais un code HTTP brut à interpréter vous-même.