Skip to main content
Les changements les plus récents sont en haut. Filtrez par produit avec les étiquettes. Une entrée marquée À vérifier peut demander une modification de votre code.
PaiementsDéveloppeurs
  • Nouveaux pays : Gabon (Airtel, Moov), Kenya (M-Pesa) et Mozambique (M-Pesa, en MZN). Nouveaux opérateurs : Moov en Côte d’Ivoire et Zamtel en Zambie. Le Ghana n’est plus proposé.
  • L’API v1 est figée : plus aucun changement cassant sans 90 jours de préavis. Voir Politique de versions.
  • Nouveau réglage : l’e-mail du contact technique qui reçoit nos annonces de changements.
  • Nouveau : POST /api/v1/fees/quote calcule le montant payé par le client, les frais et ce que vous recevez, avant tout paiement.
  • GET /api/v1/account donne vos frais (taux par canal, frais fixe carte, qui les paie), les pays mobile money ouverts et vos limites.
  • Nouveaux paramètres de session payment_method_types et allowed_countries pour choisir ce que la page de paiement propose, et {CHECKOUT_SESSION_ID} dans success_url. Voir Sessions de paiement.
  • Nouvel événement provider_status.changed quand un opérateur tombe en panne ou revient, à cocher sur votre endpoint.
  • Nouveau : GET /api/v1/events/{id}/deliveries liste chaque envoi d’un événement et chaque tentative. Renvoyer un événement à un endpoint qui l’avait déjà reçu fonctionne de nouveau.
  • Limites de débit séparées : 300 lectures et 60 écritures par minute et par clé. Voir Limites de débit.
  • Nouveau : virez entre deux soldes mobile money du même pays (MTN vers Orange au Cameroun, par exemple), depuis la page Soldes ou par POST /api/v1/wallet_transfers. Immédiat et sans frais.
  • Remboursement partiel : passez amount à POST /api/v1/payments/{id}/refunds, plusieurs fois si besoin. Le paiement reste succeeded jusqu’au remboursement complet, avec le nouveau champ amount_refunded. payment.refunded n’est envoyé qu’une fois tout le paiement rendu.
  • Nouveaux champs sur un paiement : fee_paid_by (qui a payé les frais) et payer (nom, e-mail, numéro). Le numéro saisi sur la page de paiement est aussi gardé dans payer_phone de la session.
  • Documentation corrigée : les retraits fonctionnent bien en sandbox, et le statut refunded est utilisé depuis le 13 novembre.
PaiementsSoldes et retraitsDéveloppeurs
  • Nouveau : remboursez un paiement en entier, depuis la transaction ou par POST /api/v1/payments/{id}/refunds. Frais de 1 %, au moins 100 FCFA, jusqu’à 90 jours après le paiement. Voir Rembourser un paiement.
  • Nouveaux événements payment.refunded, refund.succeeded, refund.failed et refund.canceled. Nouveaux codes d’erreur insufficient_balance et refund_not_allowed.
  • Nouveau champ status_detail sur un retrait : delayed quand l’opérateur est indisponible (le retrait peut alors être annulé), pending_processing quand il n’est pas encore parti.
  • Un retrait vers un opérateur fermé aux retraits est refusé à la demande, sans réserver le montant.
AbonnementsSoldes et retraitsDéveloppeurs
  • Nouveau statut de retrait canceled : un retrait pas encore examiné peut être annulé depuis le tableau de bord, sans mouvement d’argent. Nouvel événement payout.canceled.
  • Nouvel événement invoice.canceled : vous avez annulé une facture impayée, ses relances s’arrêtent et l’abonnement continue.
  • Un client qui paie avec un e-mail est désormais aussi un client de l’API : il apparaît dans GET /api/v1/customers.
  • Dans les logs de la console, collez un Request-Id pour retrouver l’appel exact.
PaiementsSoldes et retraitsAbonnements
  • Les retraits fonctionnent en sandbox : ils partent tout de suite et passent à paid ou failed selon le numéro de test. L’erreur payout_unavailable_in_sandbox n’est plus renvoyée.
  • Nouveau : POST /api/v1/subscriptions/{id}/advance fait passer un abonnement sandbox à son échéance.
  • La page de paiement sandbox propose une cause d’échec précise. Voir Tester les cas difficiles.
PaiementsLiens de paiement
  • Apple Pay, Google Pay et Link s’affichent avec la carte quand l’appareil de votre client les propose.
  • Un paiement en FCFA (XAF ou XOF) débite la carte en euros, au taux fixe de 1 € pour 655,957 FCFA : votre prix et votre solde ne changent pas. Votre client voit le montant en euros avant de payer, et son reçu montre les deux.
  • En FCFA comme en EUR, USD ou GBP, votre client voit aussi les moyens acceptés en euros : par exemple Bancontact, EPS, MB WAY, Satispay, Klarna ou Amazon Pay.
  • Rien à changer dans votre intégration : ces paiements restent des paiements card. Les abonnements restent en carte.
Paiements
  • À vérifier : un paiement par carte coûte désormais 6 % + 200 FCFA (0,30 en USD, EUR ou GBP). Le mobile money et les retraits ne changent pas.
  • Si vous faites payer la commission à votre client, le frais fixe est ajouté à ce qu’il paie : vous recevez toujours votre prix exact.
  • Le solde d’un paiement carte passe en disponible le jour où les fonds nous sont réellement versés, en général sous 5 jours.
PaiementsLiens de paiement
  • Votre client voit pourquoi son paiement a échoué et quoi faire : un message par cause en mobile money, et le vrai motif d’un refus de carte (solde, code de sécurité, carte expirée…).
  • « Payer autrement » reste visible sous le formulaire carte. Les champs carte sont toujours en français.
  • Le nom, l’e-mail et le téléphone donnés à une session de checkout sont pré-remplis. Un lien de paiement accepte aussi ?email=, ?name= et ?phone= : voir Liens de paiement.
  • L’écran de succès propose le reçu à télécharger, puis renvoie vers votre success_url après 5 secondes.
  • Vos liens et vos pages d’abonnement reprennent tout votre kit de marque : couleurs, police, arrondis et vos propres conditions.
  • Un lien partagé sur WhatsApp ou Facebook s’affiche à vos couleurs, avec votre logo, le titre et le montant. Seul votre nom apparaît dans l’onglet du navigateur, sur l’aperçu et sur les pages d’erreur de paiement.
  • À l’abonnement aussi, l’opérateur mobile money est trouvé d’après le numéro saisi. Votre client peut le changer.
Développeurs
Des webhooks plus sûrs et plus fiables.
  • À vérifier : la signature passe dans l’en-tête MercyPay-Signature, de la forme t=…,v1=…. v1 est le HMAC-SHA256 de {t}.{corps brut}, et une signature de plus de 5 minutes doit être refusée. L’ancien en-tête X-MercyPay-Signature n’est plus envoyé. Mettez votre vérification à jour : voir Sécurité des webhooks.
  • À vérifier : created d’un événement est une date ISO 8601, comme partout dans l’API, et l’événement porte object: "event".
  • Nouveaux en-têtes MercyPay-Event-Id, MercyPay-Event-Type et MercyPay-Delivery-Id. X-MercyPay-Event est remplacé par MercyPay-Event-Type.
  • Changer de secret ne coupe plus rien : pendant 24 heures, chaque webhook est signé avec l’ancien et le nouveau secret.
  • 8 tentatives sur 3 jours au lieu de 5 sur 1 heure 20. Un endpoint qui n’accepte rien pendant 3 jours est désactivé, et vos développeurs sont prévenus par e-mail.
  • Envoyer un test et Relancer les échecs dans la console. Dans l’API : POST /api/v1/webhook_endpoints/{id}/test, POST /api/v1/webhook_endpoints/{id}/rotate_secret et POST /api/v1/events/{id}/resend.
PaiementsAbonnementsLiens de paiementSoldes et retraitsDéveloppeursDocumentation
Une API v1 plus cohérente. À vérifier : ces changements modifient la forme des réponses et des chemins. Mettez votre intégration à jour en suivant les points ci-dessous.Identifiants et forme des objets :
  • À vérifier : chaque objet a un id préfixé selon son type (pay_…, po_…, cus_…, pm_…, sub_…, plan_…, in_…, plink_…, wal_…, cs_…), plus object, livemode et created. uuid et created_at disparaissent. Pour une session de checkout, reference est remplacée par id.
  • Les objets liés renvoient leur id. Avec expand, vous recevez l’objet entier. Voir Objets liés.
  • À vérifier : les montants d’un paiement s’appellent comme ceux d’un retrait : amount, fee_amount, net_amount. gross_amount, psp_fee_amount, platform_fee_amount et net_amount_to_merchant disparaissent. Voir Paiements.
  • À vérifier : le plan s’envoie dans plan à la création d’un abonnement ou d’un lien récurrent, et un lien récurrent le renvoie dans plan. subscription_plan_id et subscription_plan disparaissent.
  • metadata sur les paiements, retraits, clients et factures. Un paiement reprend celle de sa session, une facture celle de son abonnement. Voir Metadata.
  • Nouveau champ failure_code sur un retrait échoué, avec les mêmes codes que les paiements.
Chemins, listes et erreurs :
  • À vérifier : les chemins passent en snake_case : /api/v1/checkout_sessions, /api/v1/payment_links, /api/v1/billing_portal/sessions, /api/v1/customers/{id}/payment_methods, /api/v1/provider_status.
  • À vérifier : les listes se parcourent avec un curseur : limit, starting_after, ending_before, created[gte] et created[lte]. La réponse est {"object": "list", "url", "has_more", "next_cursor", "data"}. page, per_page, links et meta disparaissent. Voir Pagination.
  • À vérifier : une erreur est un seul objet error avec type, code, message, param, doc_url, request_id et, sur une erreur 422, errors. Lisez error.code au lieu de code. Voir Erreurs.
  • Chaque réponse porte un en-tête Request-Id, à donner au support pour désigner un appel précis.
Nouveaux endpoints :Tableau de bord et e-mails :
  • Les messages de connexion par clé d’accès et par double authentification, ainsi que les e-mails de réinitialisation du mot de passe et de confirmation d’adresse, sont maintenant en français.
  • Un retrait échoué indique un motif clair, par exemple un numéro de bénéficiaire non reconnu par l’opérateur.
AbonnementsLiens de paiementPaiementsSoldes et retraitsDéveloppeursDocumentation
Paiement avant activation et moyens de paiement du client :
  • À vérifier : un abonnement créé est incomplete jusqu’au premier paiement, en carte comme en mobile money. Redirigez votre client vers next_action.redirect_url (/abonnements/{uuid}/payer) et donnez l’accès à votre service à la réception de subscription.created. Sans paiement sous 48 heures, l’inscription est annulée. Voir Abonnements.
  • À vérifier : next_action est maintenant {"type": "redirect", "redirect_url": ...}. L’ancienne page /abonnements/{uuid}/carte redirige vers la nouvelle.
  • payment_method devient facultatif à la création : sans lui, le client choisit sur la page de paiement.
  • Un essai par client et par plan (même e-mail, carte ou numéro). Un client ne peut pas avoir deux abonnements en cours au même plan.
  • Nouveau statut unpaid et événement subscription.unpaid : en mobile money, la demande part 2 jours avant l’échéance, et l’abonnement passe à unpaid si rien n’est payé à l’échéance. Coupez alors l’accès à votre service.
  • Chaque client a ses cartes et numéros mobile money de n’importe quel pays, dont un par défaut. À l’échéance, ils sont essayés dans l’ordre. Nouveaux endpoints Clients et champ customer dans un abonnement.
  • Passer à un plan plus cher au même rythme est immédiat, contre la différence au prorata. Un plan moins cher s’applique à la prochaine échéance.
  • Nouveau champ portal_switchable sur les plans : vos abonnés peuvent passer eux-mêmes à ces plans depuis leur espace client.
  • Nouveau champ kind sur les factures : first, cycle ou proration.
  • L’espace client est refait : une page par abonnement, cartes et numéros, factures, paiement d’avance.
  • Les e-mails de rappel, d’échec de paiement et de fin d’abonnement affichent la date en toutes lettres, par exemple « le 9 novembre 2026 ».
Retraits et plafond :
  • Un retrait refusé par notre équipe vous est maintenant signalé par e-mail et par le webhook payout.failed, avec le motif dans failure_reason.
  • Le plafond mensuel des comptes en votre nom ne compte plus que les paiements réels : vos paiements de test n’entament plus votre plafond.
Liens de paiement :
  • Tout le constructeur du tableau de bord est disponible dans l’API : PATCH, archivage, suppression, tarifs, panier, champs personnalisés, métadonnées. Voir Liens de paiement.
  • Nouveaux réglages collect_phone, collect_address et after_payment_message.
  • Nouveau GET /api/v1/payment-links/{uuid}/payments et nouvel événement checkout_session.completed.
  • À vérifier : uses_count compte les paiements réussis, plus les ouvertures. Ouvrir un lien à prix fixe affiche sa page au lieu de rediriger tout de suite vers le checkout.
  • À vérifier : un lien créé sans amount est en montant libre (pricing_mode: "flexible").
Abonnements :
  • À vérifier : customer_email est obligatoire pour tout abonnement.
  • En mobile money, chaque échéance envoie une demande de paiement sur le téléphone du client, puis un lien par e-mail s’il ne la valide pas.
  • Relances à J+1, J+3 et J+7 pour la carte comme pour le mobile money, puis annulation.
  • Pause et reprise, nombre d’échéances limité (max_cycles), annulation en fin de période et retour sur l’annulation (reactivate).
  • Nouvelles factures dans l’API, avec encaissement immédiat et renvoi au client.
  • Nouvel espace client et POST /api/v1/billing-portal/sessions.
  • Nouveaux événements : subscription.updated, subscription.past_due, subscription.unpaid, subscription.paused, subscription.resumed, invoice.created et invoice.upcoming.
  • À vérifier : PATCH /api/v1/plans/{uuid} modifie le nom, la description, portal_switchable et les métadonnées. Pour archiver, appelez POST /api/v1/plans/{uuid}/archive.
  • À vérifier : dans un abonnement, plan est maintenant l’objet plan complet.
Compte, retraits et documentation :
  • Nouveau parcours de démarrage : code par e-mail à l’inscription, boutique en 5 écrans, premier paiement test guidé.
  • Une clé sandbox peut être copiée à tout moment depuis la console Développeurs. Les clés créées avant ce changement n’ont pas ce bouton : générez-en une nouvelle si besoin.
  • La page de paiement affiche des données de test en sandbox.
  • Nouveau parcours de vérification d’identité, avec recto et verso et un envoi explicite du dossier. Les dossiers déjà envoyés gardent leurs règles.
  • Connexion possible avec un code reçu par e-mail.
  • POST /api/v1/payouts accepte destination_id, l’identifiant d’un compte de retrait enregistré.
  • Chaque retrait porte un champ origin : dashboard, api ou automatic. Il reste vide pour les retraits plus anciens.
  • Nouveaux retraits automatiques, réglés solde par solde.
  • Un compte suspendu ne peut plus demander de retrait, y compris depuis le tableau de bord.
  • Un dossier refusé peut corriger ses informations avant d’être renvoyé.
  • Le guide d’intégration de carte dans votre propre formulaire est retiré. Pour cette intégration, écrivez au support.
  • Nouveaux documents légaux : activités interdites, lutte anti-blanchiment, traitement des données et conditions de l’API.
Documentation :
  • La documentation est rangée par produit, avec pour chacun une partie « Sans code » illustrée de captures en clair et en sombre, et une partie « Développeurs ».
  • La référence API est générée depuis une spec OpenAPI : chaque route a sa page avec le bouton « Essayer » et des exemples en cURL, PHP, JavaScript et Python. Les anciennes adresses redirigent vers les nouvelles.
PaiementsSoldes et retraitsDéveloppeurs
  • Chaque erreur de l’API porte un champ code stable, voir Erreurs. Testez ce champ plutôt que message.
  • Chaque événement webhook porte created et livemode, voir Événements.
  • À vérifier : les messages d’erreur disent « retrait » au lieu de « payout ». Si votre code compare le texte de message, passez au champ code. Les URL, les champs et les événements de l’API ne changent pas (/api/v1/payouts, payout.paid).
  • À vérifier : une carte refusée peut réussir ensuite si le client réessaie. Vous recevez alors payment.failed puis payment.succeeded, voir Paiements.
  • Un paiement carte non terminé passe à expired après 24 heures, avec un événement payment.failed et le failure_code transaction_expired.
  • Les numéros mobile money du Congo, de Côte d’Ivoire et du Bénin gardent leur 0.
  • Les secrets de webhook peuvent être réaffichés et régénérés depuis la console Développeurs.
PaiementsSoldes et retraitsDéveloppeurs
  • À vérifier : Idempotency-Key est obligatoire sur POST /api/v1/payments. Sans cet en-tête, l’API répond 400.
  • À vérifier : le champ psp_reference n’est plus renvoyé dans les paiements, les retraits et les webhooks.
  • Nouveau champ failure_code sur les paiements, voir la liste des codes.
PaiementsSoldes et retraitsDéveloppeurs
  • À vérifier : la commission carte par défaut est de 5,5 %. La documentation indiquait 5 %.
  • Gestion d’équipe : invitez des membres dans votre boutique et donnez-leur un rôle.
  • La chronologie d’un paiement ou d’un retrait montre chaque livraison de webhook.
  • Recherche et filtres sur les listes du tableau de bord.
  • Les actions sensibles demandent un code de vérification, et un mot de passe connu dans une fuite de données est refusé.
Développeurs
  • Les réponses rejouées avec la même Idempotency-Key sont protégées contre les requêtes simultanées, et un webhook reçu deux fois n’est traité qu’une fois.
  • Nouveaux e-mails transactionnels, aux couleurs de votre boutique.
  • Vérification d’identité refaite : compte Individuel ou Entreprise, avec un plafond d’encaissement adapté à chacun.
Paiements
  • Nouvelle page Image de marque : logo, couleurs, forme des boutons et coordonnées de contact, appliqués au checkout, aux reçus PDF et aux e-mails.
AbonnementsPaiements
  • Liens de paiement refaits : panier, plusieurs tarifs, abonnements, champs personnalisés et image de votre boutique.
  • La page de statut couvre aussi la plateforme et l’API, avec un taux de disponibilité.
AbonnementsPaiements
  • Les pages publiques ont changé d’adresse. /checkout/... devient /paiement/... et /pay/... devient /payer/.... Les anciens liens sont redirigés.
  • Nouvelle page Tarifs et pages produit pour les paiements, les liens de paiement et les abonnements.
Soldes et retraitsDéveloppeurs
  • À vérifier : Idempotency-Key est obligatoire sur POST /api/v1/payouts. Sans cet en-tête, l’API répond 400.
  • À vérifier : les retraits, les clés API, les webhooks et les paramètres de la boutique sont réservés au propriétaire.
  • Une URL de webhook vers une adresse privée ou interne est refusée.
  • Limites de requêtes sur l’inscription, la réinitialisation du mot de passe et les webhooks.
  • Acceptation des conditions d’utilisation horodatée à l’inscription.
AbonnementsPaiements
  • Premiers abonnements : facturation récurrente par carte et mobile money.
  • Connexion avec Google ou GitHub.
PaiementsDéveloppeurs
  • Paiement par carte directement depuis l’API, sans session de checkout, avec POST /api/v1/payments.
  • La clé publique live pour la carte n’est fournie qu’après validation de votre identité.
Développeurs
  • Nouvel endpoint public GET /api/v1/provider-status : la disponibilité réelle de chaque opérateur, à interroger depuis votre site sans clé API.
Paiements
  • Page de statut publique des moyens de paiement, avec 30 jours d’historique. Un opérateur en panne est grisé sur le checkout.
  • Ajoutez votre logo et votre couleur : ils s’affichent sur le checkout et les liens de paiement.
  • Reçus PDF envoyés au payeur, à votre nom, à la place du reçu du prestataire carte.
  • Support : ouvrez une demande depuis le tableau de bord.
PaiementsSoldes et retraitsDéveloppeurs
  • Le checkout propose tous les pays mobile money. Un payeur d’un autre pays paie dans sa monnaie, convertie au taux du jour. Voir Devises.
  • Option pour répercuter la commission sur votre client.
  • Soldes en attente et disponibles, et retrait du solde carte.
  • À vérifier : GET /api/v1/account ne renvoie que les soldes de l’environnement de la clé utilisée.
  • E-mails à chaque paiement reçu et à chaque changement de statut d’un retrait.
Liens de paiementPaiements
  • Nouveaux liens de paiement : une demande de paiement réutilisable, à partager.
  • Commission de 3,5 % en mobile money et 5 % par carte.
PaiementsSoldes et retraits
  • Paiement mobile money direct depuis l’API, sans session de checkout.
  • Commission de 2 % sur les retraits, détaillée dans l’API et le tableau de bord.
  • Le motif d’un paiement refusé est renvoyé, sans jamais nommer le prestataire. Un code PIN faux est indiqué clairement.
PaiementsSoldes et retraitsDéveloppeurs
  • Mobile money dans tous les pays pris en charge, avec un solde par canal, pays et opérateur.
  • Retrait depuis le solde de votre choix.
  • À vérifier : les soldes de l’API portent channel, country et operator, et un paiement mobile money porte son pays et son opérateur.
  • Les montants suivent le nombre de décimales de chaque devise (ISO 4217). Montants minimums carte en USD, EUR et GBP.
  • Inscription possible depuis n’importe quel pays pris en charge.
  • Le secret de signature d’un webhook s’affiche une fois, à la création de l’endpoint.
  • Inscription des marchands et vérification d’identité.
  • Bascule entre les environnements sandbox et live.
PaiementsSoldes et retraitsDéveloppeurs
  • Lancement de l’API v1 : sessions de checkout, paiements carte et mobile money, soldes et webhooks signés.
  • Authentification par Authorization: Bearer ou par l’en-tête X-Api-Key.