Revue de l’entité et du produit
L’entreprise contractante complète le KYB et explique produit, actionnariat, parcours client, distribution et modèle économique. L’approbation reste limitée à ce cas d’usage examiné.
Infrastructure pour fintechs
Intégrez les paiements à votre produit financier. Connectez le parcours client.
ZyndPay fournit aux fintechs approuvées des briques produit pour encaissements, comptes stablecoin custodiaux, payouts, événements signés et rapprochement. Les capacités exactes et le partage conformité sont convenus à l’onboarding ; c’est une infrastructure de paiement, pas une licence bancaire générale.
- Intégration API-first
- Custody exprimée clairement
- Aucune promesse Banking-as-a-Service
Le modèle opérationnel d’abord
Une intégration fintech commence par qui sert le client et qui déplace l’argent.
Avant le live, les équipes cartographient entités juridiques, utilisateurs, flux de fonds, devises, marchés, custody, support client et responsabilités conformité. Un schéma clair évite de confondre API de paiement, licence et modèle réglementé complet.
Partage client et conformité
Les parties identifient qui onboarde et assiste l’utilisateur, quel KYC ou KYB s’applique, qui effectue les filtrages requis et qui gère réclamations, litiges et demandes réglementaires.
Langage custody et solde
Quand ZyndPay fournit un solde consommateur, il est custodial et non bancaire. Le partenaire ne doit pas le présenter comme self-custody, épargne assurée ou produit bancaire propre.
Disponibilité pays et rails
Un concept API pris en charge ne garantit pas chaque pays, actif, réseau ou destination. Le live suit la configuration activée du compte et l’état opérationnel de chaque rail.
Parcours d’architecture
Reliez les actions du client aux résultats de paiement vérifiés.
La fintech possède son expérience produit tandis que ZyndPay expose les concepts et états approuvés. Identifiants stables, instructions idempotentes et événements signés alignent les systèmes sans prendre une transition d’écran pour la vérité du registre.
- 01
Cartographier les fonds
Documentez money in, état de compte ou custody, conversions, réservations, payouts et money out. Identifiez propriétaire juridique et source de preuve à chaque transition.
- 02
Prouver le parcours en sandbox
Modelez création, attente, succès, échec et relances sans argent réel. L’acceptation en sandbox ne vaut pas autorisation de traitement live.
- 03
Créer des instructions idempotentes
Donnez à chaque paiement ou payout une clé métier stable et gérez les relances sans doubler l’effet économique. Distinguez acceptation et achèvement du rail.
- 04
Consommer les états signés
Vérifiez et traitez les événements asynchrones, tolérez le rejeu et récupérez après interruption par rapprochement authentifié plutôt qu’en faisant confiance à la seule arrivée des événements.
- 05
Rapprocher avant de scaler
Comparez registres clients de la fintech, preuves de transaction et registre ZyndPay, puis résultats des rails. Résolvez tout écart inexpliqué avant d’augmenter volume ou automatisation.
Briques produit
Utilisez uniquement les briques nécessaires au produit approuvé.
Acceptation de paiements
Créez des flux d’encaissement pris en charge avec stablecoin, carte ou mobile money lorsqu’ils sont activés pour le compte et le contexte.
Comptes stablecoin custodiaux
Prenez en charge des parcours de solde USDT ou USDC approuvés dans le modèle custodial ZyndPay, avec paires actif-réseau et contrôles de retrait activés.
Instructions de payout
Soumettez des sorties éligibles et observez filtrage, approbation, traitement et états terminaux sans présenter l’acceptation comme une livraison.
Webhooks signés
Reliez l’état asynchrone au back-end fintech avec événements signés, relances et consommation consciente du rejeu.
Sandbox et passage au live
Testez les scénarios produit, puis complétez KYB, revue opérationnelle, identifiants et configuration du compte avant l’argent réel.
Rapprochement orienté registre
Conservez affichage client, état de transaction, frais, remboursements, règlement et preuves de payout liés mais distincts dans le reporting.
Frontière réglementaire
Une connexion API ne transfère pas toutes les responsabilités réglementées.
Le contrat et le modèle approuvé définissent le partage des responsabilités. ZyndPay n’accorde pas de licence bancaire à la fintech, ne certifie pas son statut réglementaire et ne fait pas de promesse marque blanche ou couverture de licence non étayée. Chaque partie reste responsable de ses obligations.
- Promesse client
- Décrivez custody, disponibilité, frais et finalité comme implémentés. Ne promettez ni dépôt assuré, valeur garantie, règlement universel instantané ni self-custody lorsque le produit ne les fournit pas.
- Preuve conformité
- Conservez les preuves d’onboarding, consentement, filtrage et transaction requises. Une réponse API réussie ne démontre pas que le partenaire a rempli ses propres obligations.
- Preuve commerciale
- Tarification, limites, règlement et rails activés sont propres au compte et communiqués avant le live. Aucune grille fintech universelle publique ne s’applique.
Points d’entrée techniques
Explorez les concepts publics, puis débloquez les détails privés après inscription.
API de paiement
Comprenez le cycle public de création et suivi des encaissements et sorties pris en charge.
Découvrir l’APIWebhooks signés
Concevez des consommateurs idempotents et résistants au rejeu pour les états de paiement et payout.
Découvrir les webhooksSandbox
Modelez succès, échec et relance sans confondre environnement de test et approbation live.
Découvrir la sandboxFAQ
Questions des équipes fintech
ZyndPay est-il un fournisseur Banking-as-a-Service ?
Cette page ne fait pas cette affirmation. ZyndPay fournit des capacités approuvées de paiement, stablecoin custodial, payout et produits associés. Les responsabilités juridiques et conformité sont définies pendant la qualification et au contrat.
Une fintech peut-elle intégrer des soldes ZyndPay dans son app ?
Uniquement via un produit et modèle opérationnel approuvés. Lorsqu’un solde consommateur existe, il est custodial, non bancaire et non self-custody ; responsabilités utilisateur, support, KYC, custody et information doivent être explicites.
L’intégration peut-elle commencer avant la fin du KYB ?
Le travail sandbox pris en charge peut commencer avant le live. Argent réel, identifiants production et rails activés restent soumis au KYB, à la revue opérationnelle et à la configuration du compte.
Une API signifie-t-elle que tous les rails sont disponibles partout ?
Non. Le modèle d’intégration peut être cohérent alors que les actifs, réseaux, pays, méthodes et destinations restent propres au compte et à l’opération.
Comment gérer relances et webhooks ?
Utilisez des clés d’idempotence stables, vérifiez les événements signés, tolérez relance et rejeu, puis rapprochez l’état authentifié après interruption. Une livraison dupliquée ne doit jamais créer un mouvement d’argent dupliqué.
ZyndPay publie-t-il une tarification fintech ?
Aucun taux public universel ne s’applique. Tarification, limites et règlement sont communiqués au compte qualifié dans le dashboard, les réponses API ou les conditions avant le live.
Architecture et qualification
Préparez votre intégration avec notre équipe.
Partagez entités juridiques, utilisateurs, marchés, devises, modèle de custody et sortie, volumes attendus, responsable conformité et responsable technique. Les équipes définissent ainsi la frontière produit minimale et vraie avant l’implémentation.