Communauté

Bonjour,

Je rencontre un blocage sur l'API Checkout Intent en sandbox, sur lequel j'aimerais votre aide — j'ai réussi à isoler précisément les conditions qui déclenchent le problème, et j'ai déjà éliminé plusieurs pistes de mon côté (droits du token, encodage, retries).

Contexte technique

• Backend : Node.js 24 / TypeScript, sur Firebase Cloud Functions Gen 2 (europe-west1)
• Authentification API : OAuth2 client_credentials, token demandé à chaque besoin (mis en cache côté serveur, renouvelé avant expiration)
• Environnement : sandbox (api.helloasso-sandbox.com)
• Organisation : entente-sportive-viry-chatillon-tennis-de-table
• ClientId concerné : d8719c79-e040-... (je peux communiquer l'identifiant complet en privé si besoin)

Le problème
Le POST /v5/organizations/{slug}/checkout-intents fonctionne parfaitement depuis notre backend : le checkout est créé, redirige bien vers la page de paiement HelloAsso, et le paiement carte test aboutit normalement.

Mais le GET /v5/organizations/{slug}/checkout-intents/{id} sur ce même checkout-intent, appelé depuis notre backend juste après (webhook de confirmation), échoue systématiquement en 403 Forbidden, corps de réponse vide. Reproduit sur plusieurs checkout-intents différents (94037, 64397, 64392, 94032, 93938, 64266), sur plusieurs jours, avec des retries HelloAsso qui échouent tous de la même façon.

Ce que j'ai déjà éliminé

1. Pas un problème de droits sur le token — j'ai décodé le JWT OAuth2 utilisé pour l'appel qui échoue : "urs": "OrganizationAdmin", "cps": ["AccessPublicData", "AccessTransactions", "Checkout", "PublicToolbox", "RefundManagement"]. AccessTransactions est bien présent.
2. Pas un problème d'encodage du client_secret (il contient +//) — vérifié que notre code encode correctement en application/x-www-form-urlencoded.
3. Pas un problème de validation d'organisation — mon association sandbox est validée.
   

Le test qui isole vraiment le problème
J'ai créé un checkout-intent manuellement via le playground Swagger de votre documentation (même clientId, en navigation privée pour éviter toute session utilisateur), puis fait le GET sur cet id — succès (200), mêmes credentials OAuth2 client_credentials, aucun cookie de session impliqué.

En revanche, le GET sur un checkout-intent créé par notre backend (même clientId, mêmes droits token) échoue toujours en 403.

La seule variable qui change est le canal de création du checkout-intent. Y a-t-il une différence de traitement connue entre les checkout-intents créés de façon interactive et ceux créés par API pure en sandbox ? Ou un flag/état particulier qui pourrait expliquer ce 403 uniquement sur ces derniers ?

Merci d'avance pour votre aide — je reste disponible pour fournir plus de détails si besoin.