Modèles

Noryo Merchant API échange peu d'objets, tous décrits dans le contrat OpenAPI et dans la référence de l'API. Cette section les présente du point de vue de l'intégrateur : ce que chaque champ garantit, quand il est présent, et quand il vaut null.

La carte des objets

Enrichment
├── enrichment_id
├── merchant ─────── Merchant | null
│                    ├── name, category, logo_url, confidence
│                    └── location ── { city, postal_code } | null
├── enrichment ───── status, reason, environment, source, customized
└── usage ────────── billable, units, deduplicated, deduplicated_by

Les relations entre identifiants

Quatre identifiants circulent, chacun à son échelle :

Leurs relations :

• Une transaction a un ou plusieurs enrichissements : le premier, puis un par rafraîchissement. L'un d'eux est son résultat courant. Voir Cycle de vie.
• Une Idempotency-Key désigne une seule requête pendant 24 heures, donc au plus un enrichissement.
• Une requête peut donner plusieurs tentatives : chaque reprise a son propre Noryo-Request-Id, même quand elle rend la réponse mémorisée.
• Un enrichissement sans external_transaction_id n'appartient à aucune transaction : il ne se déduplique pas et ne se rafraîchit pas.

Règles de présence

• merchant est toujours présent : un objet, ou null quand le statut est not_found.
• merchant.location est toujours présent quand merchant est un objet : un objet, ou null.
• merchant.category et merchant.logo_url sont omis quand ils sont inconnus.
• enrichment.reason est toujours présent : une raison, ou null.
• usage.deduplicated_by est toujours présent : external_transaction_id, ou null.

Écrivez un client qui ignore les champs de réponse qu'il ne connaît pas, et qui accepte qu'un champ facultatif soit absent.