Présentation
Un versement a lieu lorsque de l'argent est transféré d'une partie à une autre. (par exemple, lorsque de l'argent est envoyé de la banque de l'intégrateur de paiement à la banque de Google). Le schéma suivant illustre ce processus.
Fonctionnement du flux
Le schéma suivant illustre un exemple de fonctionnement du flux de paiement.
Intégrateur des paiements pour les versements à Google
Voici une liste d'objets utilisés dans ce schéma:
- Serveur Google: serveur backend de Google qui vérifie l'authentification, ainsi que d'autres tâches d'authentification.
- Intégrateur de paiement: entreprise qui propose un mode de paiement à ses clients.
- Banque de l'intégrateur de paiement: banque émettrice que l'intégrateur utilise pour les transactions financières.
- Banque Google: banque utilisée par Google pour les transactions.
La procédure de paiement ci-dessus commence par le serveur de Google.
- Les jours T+N, Google envoie la notification de relevé de paiement (
remittanceStatementNotification). - L'intégrateur de paiements informe le serveur Google qu'il a bien reçu la notification de relevé de paiement.
- L'intégrateur de paiements envoie également les détails du relevé de paiement (
remittanceStatementDetails). - Le serveur de Google répond avec l'instruction ainsi que le champ "transactionDetails".
- L'intégrateur de paiements les rapproche.
- L'intégrateur de paiements envoie un message (
acceptRemittanceStatement) au serveur Google indiquant que l'instruction a été acceptée. - L'intégrateur de paiements envoie également un message indiquant que la banque de l'intégrateur de paiement doit envoyer des fonds à la banque Google.
- La banque de l'intégrateur de paiement effectue un virement à la banque Google.
Bonnes pratiques et autres considérations
Durée
Les conditions de paiement sont définies dans le contrat et généralement exprimées sous la forme "T+N". T correspond à la fréquence à laquelle un relevé de paiement est généré et à la durée de la période couverte par chaque relevé. Dans l'exemple suivant, "T" correspond à un jour de transaction. N correspond au nombre de jours suivant la période de transaction où arrive le relevé de paiement.
Si N est configuré sur 2 et qu'une transaction est comptabilisée à 23:59:59.999 dans le fuseau horaire de facturation le mardi, elle apparaîtra dans un relevé le jeudi.
Déclarations négatives ou nulles
Les jours où il n'y a pas de transaction au cours de la période de facturation, aucune notification de relevé de paiement ne sera envoyée. En outre, si des remboursements au cours d'une période de facturation se traduisent par un montant net négatif de la facture, aucun relevé de paiement ne sera envoyé non plus. Ces transactions seront toutefois reportées sur la facture nette positive suivante, pour laquelle la notification de relevé de paiement sera envoyée. Si le montant net d'une transaction est nul pour une période de facturation donnée, des notifications de relevé de paiement sont envoyées.
Limites
Vous trouverez ci-dessous quelques exemples avec différentes limites. Une limite transactionnelle correspond au moment où la transaction commence ou fait l'objet d'un commit. N'oubliez pas que l'horodatage comptable correspond au moment où Google a comptabilisé cette transaction. Les limites d'un relevé de paiement commencent à 00:00:00.000 et se terminent à 23:59:59.000.
Transaction dans les limites
| Événement | |
|---|---|
| Prise de vue | requestHeader.requestId
001 requestHeader.requestTimestamp |
| RemittanceStatementNotification | requestHeader.requestTimestamp
01/03/2017 03:17:18.132 billingPeriod.startDate 01/01/2017 00:00:00.000 billingPeriod.endDate La capture de la notification 01/01/2017 93:59 au-dessus de 90.19. |
Limites du fractionnement des transactions
L'une des captures ci-dessous comporte tous les codes temporels au 01/01/2017, mais elle n'est prise en compte qu'à partir du 02/01/2017.
| Événement | |
|---|---|
| Prise de vue | requestHeader.requestId
001 requestHeader.requestTimestamp |
| Prise de vue | requestHeader.requestId
002 requestHeader.requestTimestamp 01/01/2017 23:59:58.253 responseHeader.responseTimestamp 01/01/2017 23:59:59.879 accounting00 2/0:0.0/01. |
| RemittanceStatementNotification | requestHeader.requestTimestamp
03/01/2017 03:17:18.132 billingPeriod.startDate 01/01/2017 00:00:00.000 billingPeriod.endDate La notification de refacturation 23:59 |
| RemittanceStatementNotification | requestHeader.requestTimestamp
01/03/2017 00:27:34.321 billingPeriod.startDate 02/01/2017 00:00:00.000 billingPeriod.endDate Cette notification de refacturation 23:59 Puisque 002 a été comptabilisé le 02/01/2017, et non le 01/01/2017. |
Rapprochement
Il peut arriver que Google envoie un relevé de paiement plus tard que prévu. C'est le cas, par exemple, si Google rencontre un bug qui retarde d'une journée la notification de l'attestation de paiement.
Si la méthode remittanceStatementDetails renvoie des transactions qui n'ont pas été effectuées au cours de la période de facturation par l'intégrateur, celui-ci doit immédiatement en informer Google. Autre possibilité : il y a des transactions que l'intégrateur attend, mais qui ne sont pas renvoyées. Une fois l'écart résolu, Google peut envoyer un nouveau relevé de paiement avec un nouvel ID.
Acceptation de la déclaration de paiement
Une instruction est considérée comme acceptée par l'intégrateur une fois que celui-ci a appelé la méthode acceptRemittanceStatement.
Les relevés doivent être payés dans les conditions nettes définies dans le contrat après acceptation. Les contestations doivent être gérées manuellement entre l'intégrateur et le responsable de compte.
Paiement
Les relevés de paiement fournissent les informations nécessaires concernant le montant à payer. Chaque relevé doit être payé dans son intégralité. En cas de disparité, l'intégrateur doit contacter son responsable de compte pour résoudre le litige. Dans ce cas, le relevé peut ne pas être intégralement payé.
Précision
Chaque frais est calculé à la précision définie comme le nombre d'unités mineures spécifié dans la norme ISO 4217 pour cette devise. Par exemple, INR et USD utilisent des unités mineures à deux chiffres, et JPY, des unités mineures à deux chiffres.
Si davantage de décimales sont nécessaires pour représenter les frais, Google arrondira à la petite unité mineure la plus proche. Les égalités la plus proche seront également arrondies à la tranche mineure la plus proche. Par exemple, si vous utilisez les unités mineures à deux chiffres de l'INR:
| Frais calculés | Frais arrondis |
|---|---|
| 0.013 | 0,01 |
| 0,015 | 0,02 |
| 0,025 | 0,02 |
| -0.013 | -0,01 |
| -0,025 | -0,02 |
Cette valeur sera arrondie à chaque transaction, et non de façon groupée sur le relevé.