Dans quel délai les mises à jour des contrôles de dépenses prennent-elles effet ?

Les modifications effectuées via l'endpoint PATCH /cards/{cardId}/controls sont propagées au réseau d'autorisation dans les 200 ms. La prochaine tentative d'autorisation sur la carte sera évaluée par rapport au jeu de règles mis à jour, rendant les contrôles de dépenses Fyatu effectivement en temps réel pour toutes fins pratiques.

Puis-je définir des contrôles au niveau du programme plutôt que par carte ?

Oui. Fyatu prend en charge un modèle de contrôle à deux niveaux : des paramètres par défaut au niveau du programme qui s'appliquent à toutes les cartes d'un BIN, et des remplacements par carte qui étendent ou restreignent ces paramètres par défaut. Le jeu de règles effectif d'une carte est l'intersection des règles du programme et des règles au niveau de la carte, ce qui signifie qu'une carte ne peut jamais dépasser les limites à l'échelle du programme même si ses propres limites sont plus élevées.

Comment les codes MCC sont-ils structurés dans l'API ?

L'API de contrôles accepte à la fois les codes MCC individuels (entiers à 4 chiffres selon la norme ISO 18245) et les chaînes de groupe MCC (par ex., "VOYAGE", "RESTAURATION", "CARBURANT") qui correspondent aux ensembles de codes définis par Fyatu. Vous pouvez mélanger des codes individuels et des alias de groupe dans le même tableau de liste blanche ou noire.

Que se passe-t-il lorsqu'une carte atteint son plafond journalier en cours de transaction ?

Si une transaction devait amener les dépenses journalières cumulées à dépasser le plafond, l'autorisation complète est refusée même si le montant de la transaction lui-même est dans la limite par transaction. Les approbations partielles par rapport au solde journalier restant ne sont pas appliquées automatiquement, mais peuvent être mises en œuvre via un gestionnaire webhook JIT qui lit la marge restante et renvoie un montant modifié.

Les règles de vélocité peuvent-elles distinguer les transactions d'achat et les retraits DAB ?

Oui. Les règles de vélocité peuvent être limitées à un filtre de type de transaction — achats, avances de trésorerie, retraits DAB ou transactions en ligne — à l'aide du champ `transactionTypes` sur l'objet de règle. Cela vous permet, par exemple, d'autoriser 10 transactions d'achat par jour tout en limitant les retraits DAB à 2.

Les contrôles de dépenses sont-ils évalués avant ou après mon webhook JIT ?

Les contrôles de dépenses au niveau du réseau (blocages MCC, restrictions géographiques, limites par transaction, plafonds journaliers) sont évalués en premier, avant que le webhook JIT ne soit envoyé. Si la transaction est refusée au niveau du contrôle, aucun webhook n'est envoyé et aucune latence du gestionnaire JIT n'est consommée. Cet ordre réduit le trafic webhook inutile et simplifie la logique de votre gestionnaire.

Dans quel délai les mises à jour des contrôles de dépenses prennent-elles effet ?

Les modifications effectuées via l'endpoint PATCH /cards/{cardId}/controls sont propagées au réseau d'autorisation dans les 200 ms. La prochaine tentative d'autorisation sur la carte sera évaluée par rapport au jeu de règles mis à jour, rendant les contrôles de dépenses Fyatu effectivement en temps réel pour toutes fins pratiques.

Puis-je définir des contrôles au niveau du programme plutôt que par carte ?

Oui. Fyatu prend en charge un modèle de contrôle à deux niveaux : des paramètres par défaut au niveau du programme qui s'appliquent à toutes les cartes d'un BIN, et des remplacements par carte qui étendent ou restreignent ces paramètres par défaut. Le jeu de règles effectif d'une carte est l'intersection des règles du programme et des règles au niveau de la carte, ce qui signifie qu'une carte ne peut jamais dépasser les limites à l'échelle du programme même si ses propres limites sont plus élevées.

Comment les codes MCC sont-ils structurés dans l'API ?

L'API de contrôles accepte à la fois les codes MCC individuels (entiers à 4 chiffres selon la norme ISO 18245) et les chaînes de groupe MCC (par ex., "VOYAGE", "RESTAURATION", "CARBURANT") qui correspondent aux ensembles de codes définis par Fyatu. Vous pouvez mélanger des codes individuels et des alias de groupe dans le même tableau de liste blanche ou noire.

Que se passe-t-il lorsqu'une carte atteint son plafond journalier en cours de transaction ?

Si une transaction devait amener les dépenses journalières cumulées à dépasser le plafond, l'autorisation complète est refusée même si le montant de la transaction lui-même est dans la limite par transaction. Les approbations partielles par rapport au solde journalier restant ne sont pas appliquées automatiquement, mais peuvent être mises en œuvre via un gestionnaire webhook JIT qui lit la marge restante et renvoie un montant modifié.

Les règles de vélocité peuvent-elles distinguer les transactions d'achat et les retraits DAB ?

Oui. Les règles de vélocité peuvent être limitées à un filtre de type de transaction — achats, avances de trésorerie, retraits DAB ou transactions en ligne — à l'aide du champ `transactionTypes` sur l'objet de règle. Cela vous permet, par exemple, d'autoriser 10 transactions d'achat par jour tout en limitant les retraits DAB à 2.

Les contrôles de dépenses sont-ils évalués avant ou après mon webhook JIT ?

Les contrôles de dépenses au niveau du réseau (blocages MCC, restrictions géographiques, limites par transaction, plafonds journaliers) sont évalués en premier, avant que le webhook JIT ne soit envoyé. Si la transaction est refusée au niveau du contrôle, aucun webhook n'est envoyé et aucune latence du gestionnaire JIT n'est consommée. Cet ordre réduit le trafic webhook inutile et simplifie la logique de votre gestionnaire.

FONCTIONNALITÉ PLATEFORME

Contrôles de Dépenses Dynamiques

Définissez et mettez à jour les règles de dépenses par carte en temps réel. Blocages par catégorie MCC, limites par transaction, plafonds journaliers/hebdomadaires, restrictions géographiques — tous ajustables via un seul appel API avec effet immédiat.

Commencer Voir l'API d'Émission de Cartes

REST API · Webhooks · Real-time

Par carte

Granularité

Temps réel

Mise à jour des règles

MCC · Géo · Vélocité

Dimensions de contrôle

Analyse Technique

Comment ça Marche

L'architecture technique de Contrôles de Dépenses Dynamiques — intégrée dans chaque programme de cartes Fyatu.

MCC

Liste Blanche / Noire MCC

Restreignez ou autorisez les dépenses par Code de Catégorie Marchand au niveau de la carte. Acceptez une liste de groupes MCC autorisés (par ex., voyage et restauration uniquement) ou bloquez des catégories spécifiques (par ex., jeux d'argent, échanges de cryptomonnaies) grâce à une configuration basée sur des tableaux qui se met à jour instantanément via API.

LIMITE

Limites par Transaction

Définissez un montant maximum pour toute autorisation unique. Les transactions dépassant le seuil sont automatiquement refusées par le réseau Fyatu avant même qu'un webhook JIT ne soit envoyé, réduisant la latence et la charge du gestionnaire pour les rejets évidents.

Règles de Vélocité

Plafonnez le nombre de transactions réussies dans une fenêtre temporelle glissante — par minute, heure, jour ou intervalle personnalisé. Utile pour prévenir les attaques de test de carte ou appliquer des politiques de fréquence de transaction spécifiques au cas d'usage.

Restrictions Géographiques

Autorisez ou bloquez les transactions par pays ou région à l'aide des codes pays ISO 3166-1. Combinez avec les données du pays du marchand dans l'événement d'autorisation pour créer des listes blanches géographiques précises pour les programmes de voyage ou les produits géo-restreints.

Plafonds Journaliers / Hebdomadaires

Définissez des plafonds de dépenses cumulatives qui se réinitialisent sur une base calendaire ou glissante. Plafonnez les cartes individuelles pour le contrôle budgétaire ou définissez des limites agrégées à l'échelle du programme pour gérer votre exposition BIN et vos besoins de flottant.

Cas d'Usage

Qui Bénéficie de Contrôles de Dépenses Dynamiques

Secteurs et plateformes qui utilisent Contrôles de Dépenses Dynamiques via l'API d'émission de cartes Fyatu.

Notes de Frais d'Entreprise

Émettez une carte par employé avec des blocages MCC spécifiques au département et des plafonds de dépenses mensuels. Mettez à jour les limites instantanément lorsque les budgets changent, sans réémission de carte.

Avantages Salariés

Restreignez les cartes d'avantages aux catégories de marchands éligibles — bien-être, livraison de repas, services de transport — garantissant que les dépenses restent dans les règles du programme sans réconciliation manuelle.

Campagnes Marketing

Distribuez des cartes de campagne à usage unique ou multiple verrouillées sur des enseignes ou codes MCC spécifiques, avec expiration automatique et un plafond de dépenses fixe par destinataire.

Voyage

Activez des restrictions géographiques qui se déverrouillent automatiquement pour les corridors de voyage approuvés, ou émettez des cartes de voyage avec des limites élevées et un accès MCC élargi qui se rétablissent à la fermeture de la fenêtre de voyage.

Décaissements de Prêts

Débloquez des fonds de prêt sur des cartes dédiées restreintes aux catégories de marchands approuvées (par ex., fournitures de construction, médical), garantissant l'utilisation des fonds sans surveiller les justificatifs individuels.

Programmes Gouvernementaux

Configurez des cartes de prestations avec des règles de catégories strictes et des contraintes géographiques pour garantir que les fonds des programmes sociaux sont dépensés conformément aux exigences politiques et aux obligations d'audit.

FAQ