Capacités du compte

Les trois modes

account_type dit ce que le marchand possède chez Wajub et où se trouve l'argent. Tout le reste — capacités, commission, consentement, webhooks, KYC — est identique dans les trois. Le mode est choisi à la création de la connexion et ne change jamais ensuite : en changer modifierait ce que le marchand a accepté, c'est donc une nouvelle connexion qu'il accepte à nouveau.

Deux règles en découlent, et deux seulement :

• une connexion lite refuse de lancer un paiement tant que le marchand n'est pas sur le rail Wajub (409) — elle existe pour que la commission soit prélevée à la source et le versement automatique, et les deux exigent que l'argent passe par Wajub ;
• une connexion relay n'a pas d'onboarding : il n'y a aucun compte marchand à revendiquer.

Les onze capacités

Une connexion reçoit un sous-ensemble de cette liste fermée. Au moins une capacité est obligatoire à la création. Une valeur inconnue est refusée avec 422.

Chaque ressource déclare ce qu'elle exige

Chaque route déclare la capacité qu'elle exige, et une route qui n'en déclare aucune ne peut pas être appelée avec X-Sync. Le refus est la règle par défaut : une capacité non accordée est une capacité que la plateforme n'a pas.

Une capacité ne couvre que ce que la connexion a apporté

Les capacités disent quoi ; la connexion dit à qui. Avec X-Sync, une plateforme voit les paiements qu'elle a lancés, les remboursements de ces paiements, les clients qui ont acheté par son intermédiaire et les versements qu'elle a envoyés — jamais les ventes directes du marchand, jamais celles d'une autre plateforme.

write, subscriptions et analytics ne désignent aujourd'hui aucune ressource : elles sont enregistrées sur la connexion et montrées au marchand, mais rien ne les vérifie encore.

Modifier les conditions d'une connexion active

Les capacités et la tarification sont ce que le marchand a accepté : une fois la connexion active, elles se proposent au lieu de se modifier. PUT /accounts/{id} répond 202 Accepted et renvoie la proposition dans pending_changes ; la connexion continue de fonctionner aux conditions en vigueur jusqu'à ce que le marchand accepte ou refuse depuis son dashboard.

Les ventes déjà réalisées conservent les conditions sous lesquelles elles ont eu lieu : un changement de tarif ne retarife jamais une commission déjà prélevée. Tant que la connexion est pending, personne n'a rien accepté et PUT applique le changement directement, avec un 200.

Tarification

La tarification représente ce que votre plateforme retient sur l'activité du compte connecté. Elle se compose de plusieurs règles associées à la connexion, pas d'un nombre unique. POST /accounts crée la première règle à partir de l'objet pricing.

Les deux types se cumulent au lieu de se concurrencer. Une règle qui contient un pourcentage et des frais fixes prélève le pourcentage du montant, puis ajoute la valeur fixe. Elle applique ensuite le plancher, puis le plafond, dans cet ordre.

Calcul des frais

Cette séquence explique tous les chiffres présents dans un événement fee.received.

L'étape 6 est idempotente, et la base de données le garantit : un paiement porte au plus une commission, quel que soit le comportement de l'événement qui l'a déclenchée. L'étape 7 est comptabilisée dans la devise de règlement de la vente, pour que le ledger ne porte jamais de position de change ; la devise des frais et le taux appliqué sont enregistrés sur le mouvement.

Une commission est une part d'une vente : une vente défaite emporte sa part avec elle.

Quand la vente est remboursée

commission_refund_policy, défini sur la connexion, décide de ce qui revient.

Définissez-la avec POST /accounts, et ne la modifiez avec PUT /accounts/{id} que tant que la connexion est encore pending — c'est une condition commerciale que le marchand a acceptée. Rien n'est jamais rendu deux fois, et plusieurs remboursements sur une même vente ne peuvent jamais rendre plus que ce qui a été prélevé.

Conditions

Une règle peut contenir des conditions qui déterminent si elle s'applique.

Les conditions permettent de prélever une commission différente sur les petits paniers ou d'exempter une devise. Une connexion avec plusieurs règles doit en posséder une sans condition pour servir de repli. Dans le cas contraire, un paiement qui ne correspond à aucune règle ne porte aucune commission.

Ce qui reste librement modifiable

Deux champs survivent à l'acceptation sans l'accord du marchand, et seulement ces deux-là.

La suspension d'une connexion arrête à la fois les paiements entrants et les transferts sortants. Elle émet account.payment_suspended. Utilisez-la lorsque vous auriez autrement besoin de révoquer une capacité. Contrairement à une capacité, elle est réversible.