Skip to main content
Créez ou actualisez une session de paiement pour une commande Pending. L’action de paiement accédera au canal de paiement et peut modifier le statut de la commande ; vous devez confirmer l’ID de la commande, le montant et le mode de paiement avant l’appel.

​
Aperçu de l’interface

​
Limites du paiement anonyme

L’accès anonyme est utilisé lorsque la session de connexion est perdue après l’ouverture d’un lien de paiement copié ; il ne nécessite pas et ne doit pas inclure de Account Token à long terme. Les appels anonymes :
  • autorisent uniquement les modes de paiement par redirection hébergée configurés côté serveur ;
  • utilisent de manière fixe la page de paiement pour ordinateur ;
  • ne peuvent pas réclamer des commandes à prix nul ;
  • sont limités par IP et par commande individuelle ;
  • renvoient une projection minimale de la commande, sans compte, Application ni metadata interne.
Les appelants authentifiés doivent être le propriétaire de la commande ou un super administrateur. Les méthodes telles que X402 et l’échange de récompenses, qui nécessitent un contexte utilisateur, ne peuvent pas être appelées anonymement.

​
Exemples de requêtes

Modes de paiement nécessitant une authentification :
pay_way utilise les valeurs réelles prises en charge par le modèle de commande, par exemple WechatPay, AliPay, Stripe, Card, Airwallex, X402, PayPal, AppleIAP, Reward, BankTransfer. Chaque valeur n’est pas forcément disponible pour les requêtes anonymes ou sur chaque site.

​
Description de la réponse

La réponse en cas de succès est l’objet de commande mis à jour, qui fournit généralement le point d’entrée de l’étape suivante via pay_url ; selon le mode de paiement, elle peut également renvoyer, dans des champs contrôlés, les informations nécessaires au client pour poursuivre le paiement. Les réponses anonymes utilisent une liste blanche minimale de champs ; le propriétaire authentifié obtient les détails complets. Ne vous appuyez pas sur d’anciens noms de champs tels que payment_url, qr_code_url ou payment_method ; le contrat Order actuel utilise pay_url et pay_way.

​
Achats intégrés iOS

Le propriétaire connecté de la commande peut transmettre pay_way: "AppleIAP". Cette requête met à jour la commande en attente de paiement selon metadata.apple_price du forfait sélectionné et supprime la réduction ; elle ne génère aucun débit, n’accorde aucun crédit et ne renvoie aucun lien de paiement. Les anciennes commandes en attente de paiement doivent d’abord effectuer cette étape, puis lancer le paiement natif Apple. Seul un forfait Usage disposant d’un produit Apple et d’un prix configurés est pris en charge ; les forfaits non pris en charge ou les commandes groupées renvoient 400. Après le paiement natif Apple, soumettez transaction_id via /api/v1/orders/{id}/apple-verify/ afin de terminer la vérification côté serveur et l’attribution des crédits. La quantité de crédits provient du forfait ; le montant utilise un prix prédéfini en dollars américains indépendant d’Apple, sans cumul de réduction membre ni de majoration du site ; le montant débité dans la devise locale pour les autres régions dépend de la page de confirmation Apple.

​
Erreurs et nouvelles tentatives

  • La commande n’est pas Pending : renvoie 400 ; ne recréez pas de session de paiement.
  • pay_way n’est pas fourni : les commandes non nulles renvoient 400.
  • Un appel anonyme utilise un mode non autorisé ou une commande à prix nul : renvoie 403 ; reconnectez-vous et réessayez en tant que propriétaire.
  • L’appelant est authentifié mais n’est pas le propriétaire de la commande : renvoie 403.
  • Échec du canal de paiement : ne soumettez pas aveuglément à nouveau ; consultez d’abord les détails de la commande, puis réessayez après avoir confirmé qu’elle est toujours Pending.

​
Interfaces associées