Sous-comptes

Les sous-comptes permettent à une plateforme de connecter des marchands et d'agir pour leur compte, dans le cadre de Sync. Un paiement fait par une connexion appartient au marchand ; la commission de la plateforme, fixée par la pricing de la connexion, est créditée à la plateforme, ou lui est due quand le marchand encaisse sur ses propres prestataires (Paiements fractionnés).

Endpoints

L'objet Account (sous-compte)

Créer un sous-compte

L'objet pricing accepte percentage_fee, fixed_fee, max_fee, min_fee (tous facultatifs, numériques) et currency (obligatoire dès qu'un frais fixe, minimum ou maximum est défini). email est l'adresse du marchand : Wajub y envoie le rappel d'invitation trois jours avant l'expiration de l'invitation. Elle est conservée dans profile.email, et PUT /accounts/{id} la modifie. metadata vous appartient et est renvoyé sur l'objet. Une reference déjà utilisée par l'une de vos connexions de l'environnement, connexions annulées comprises, répond 422. Au-delà de 50 invitations ouvertes, l'appel répond 429 (la limite) :

curl https://api.wajub.com/accounts \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -H "Content-Type: application/json" \
  -d '{
    "reference": "vendor-482",
    "capabilities": ["payments"],
    "email": "contact@vendor-482.example",
    "pricing": { "percentage_fee": 10, "currency": "XAF" }
  }'

Agir pour le compte d'un sous-compte : l'en-tête X-Sync

Une fois un sous-compte active, la plateforme peut agir en tant que ce sous-compte en envoyant son id dans l'en-tête X-Sync, avec sa propre clé d'API. Quand il est présent et valide, la requête s'exécute sur le sous-compte au lieu de la plateforme, les ressources sont créées sous le sous-compte, et sa propre pricing s'applique automatiquement.

Ce que la plateforme atteint, c'est ce que cette connexion a apporté : ses paiements, avec leurs remboursements et leurs litiges, les clients qui ont acheté par elle ou qu'elle a créés ou désignés par e-mail ou téléphone (sans les notes, le motif de blocage ni les metadata du marchand, et jamais supprimés par elle), les liens, factures et bénéficiaires qu'elle a créés, les payouts qu'elle a envoyés et les événements qui concernent tout cela. Les ventes, liens, factures et bénéficiaires propres au marchand, et ce qu'ont apporté d'autres plateformes, restent hors de portée quelles que soient les capacités accordées, et répondent 404. Types de compte détaille chaque ressource.

curl https://api.wajub.com/payments \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -H "X-Sync: acc_7Yh2Mp" \
  -d '{ "amount": 10000, "currency": "XAF", "email": "client@example.com" }'

Sur une connexion live, PUT /accounts/{id} ne change pas capabilities ni pricing directement : il répond 202 Accepted avec la proposition dans pending_changes, et le marchand l'accepte ou la refuse dans son propre dashboard. payment_status et callback s'appliquent toujours immédiatement.

Chaque ressource indique la capacité qu'elle exige, et une ressource qui n'en indique aucune ne peut pas du tout être atteinte avec X-Sync. C'est le cas de /accounts/*, que vous gérez toujours avec votre propre clé, et de ce qui appartient à tout le compte du marchand plutôt qu'à une connexion : le solde, les endpoints de webhook, Shield, Tax et wajub listen.