Pour permettre aux utilisateurs de finaliser leurs achats, vous devez implémenter l'intégration du paiement natif. Pour cela, vous devez créer une API REST standard permettant à Google de gérer de manière programmatique le processus de paiement avec vos serveurs. Cette méthode offre l'expérience la plus fluide aux utilisateurs. Dans un premier temps, Google affichera l'interface utilisateur pour l'acheteur, mais prévoit de proposer des expériences plus agentiques à l'avenir.
Processus de paiement
L'intégration native nécessite de créer une API RESTful que Google peut appeler pour créer et gérer des sessions de paiement.
Le processus global est le suivant :
- Créer une session de paiement : l'utilisateur et, éventuellement, un agent ajoutent des articles à la session de manière itérative.
- Transfert vers une UI Google : une fois que l'utilisateur décide de passer au paiement, l'agent (s'il est actif) passe le contrôle à une interface Google (en transmettant les données de la session de paiement).
- Paiement manuel : l'utilisateur interagit désormais uniquement avec l'UI Google pour renseigner les informations sensibles de traitement et de paiement, puis envoyer la commande. L'agent n'intervient pas dans cette étape, ce qui garantit le déterminisme.
- Finalisation et retour : l'interface utilisateur Google affiche une page de remerciement pour confirmer la commande. Si vous le souhaitez, l'utilisateur peut être redirigé vers l'agent, qui a peut-être déjà été informé de l'achat.
Cycle de vie de l'état de la session de paiement
À mesure que l'utilisateur progresse dans le processus de paiement, vous devez mettre à jour l'état status de la session de paiement pour refléter sa progression. La session passe par le cycle de vie suivant :
incomplete: état initial lors de la création d'une session. Cela indique que des informations obligatoires (telles que les modes de livraison, les taxes ou les informations sur l'utilisateur) sont manquantes ou non calculées.ready_for_payment: état à utiliser une fois que l'utilisateur a mis à jour son adresse de livraison et que vous avez calculé les options et les totaux de livraison, mais avant que le mode de paiement ne soit finalisé.ready_for_complete: état à utiliser lors de l'hydratation complète de l'objet de paiement, une fois que le mode de paiement est sélectionné et que tous les détails de la commande sont validés.completed: état final renvoyé une fois le paiement traité et la commande passée.canceled: état renvoyé si la session de paiement est annulée.error: état renvoyé si une erreur de logique métier irrécupérable empêche le règlement. Cet état est disponible dans la version2026-04-08et ultérieure de l'UCP.
Processus de paiement pour plusieurs articles :
Google accepte désormais plusieurs éléments distincts dans une même session de paiement. Le processus général est le suivant :
- L'utilisateur initie le paiement depuis une interface compatible avec UCP (par exemple, en cliquant sur "Acheter maintenant" pour un produit).
- L'appel
POST /checkout-sessionsest effectué, y compris tous les éléments distincts du tableauline_items. Le tableauline_itemscontiendra un objet distinct pour chaque article unique acheté. - L'utilisateur peut mettre à jour son mode de paiement, ses informations de traitement ou appliquer des remises à l'aide d'appels
PUT /checkout-sessions/{id}. - Lorsque l'utilisateur clique sur le bouton "Payer avec GPay", l'
POST /checkout-sessions/{id}/completeest effectué.
Authentification
Pour en savoir plus sur la sécurisation de vos points de terminaison de l'API pour le paiement natif, y compris les méthodes d'authentification compatibles telles que les clés API et OAuth 2.0, consultez le guide Authentification et sécurité.
Outils pour les développeurs
Si vous avez besoin d'aide pour implémenter l'API pour le paiement natif, consultez les ressources suivantes dans le dépôt GitHub de l'Universal Commerce Protocol :
- Dépôt GitHub UCP : explorez le dépôt principal pour obtenir une documentation complète, des spécifications et des ressources de la communauté.
- SDK : utilisez les kits de développement logiciel pour accélérer votre intégration. Des SDK spécifiques à chaque langage sont disponibles, y compris :
Tests de conformité : validez vos points de terminaison de l'API par rapport à la spécification UCP à l'aide de la suite de tests de conformité .
Vous pouvez ainsi vous assurer que votre implémentation répond aux normes et aux comportements requis.
Nous vous recommandons vivement d'utiliser ces outils pour simplifier votre processus de développement et de test.
Objectifs de niveau de service
Les objectifs de niveau de service (SLO) suivants s'appliquent aux points de terminaison de l'API REST pour le paiement natif. Les entreprises qui s'intègrent à Google doivent respecter ces objectifs de performances et de disponibilité des API.
| Point de terminaison | Disponibilité | Latence (50e centile) | Latence (95e centile) |
|---|---|---|---|
POST /checkout-sessions (Créer) |
>= 95% | <= 1 seconde | <= 4 secondes |
PUT /checkout-sessions/{id} (Mettre à jour) |
>= 95% | <= 1 seconde | <= 5 secondes |
POST /checkout-sessions/{id}/complete (Terminer) |
>= 95% | <= 6 secondes | <= 10 secondes |
La latence du 50e centile indique qu'au moins 50% des requêtes devraient être traitées dans ce délai. La latence du 95e centile indique qu'au moins 95% des requêtes devraient être traitées dans ce délai.
Étapes suivantes
Consultez les charges utiles de l'API de paiement et les détails techniques de l'implémentation pour votre version d'UCP :