Refundable One Time Payment Code
Overview
Google Standard Payments supports cash-based FOPs (forms of payment) like convenience store purchases (such as a 7-Eleven). At a high level, a user who wants to pay for goods generates a reference number through the Payment integrator. The user then takes this reference number to a convenience store, kiosk, or bank and pays the reference number.
![]() |
![]() |
![]() |
Concepts and terminology
記号と規則
“しなければならない”というキーワードは禁止事項:「必須」「SHALL」"できません"「すべきです」「すべきでなければ」「推奨」「も構いません」および「省略可」RFC 2119 に記載されているとおりに解釈されます。
タイムスタンプ
すべてのタイムスタンプは、UTC の Unix エポック(1970 年 1 月 1 日)からのミリ秒数で表されます。
例:
- 2019 年 4 月 23 日午後 8:23:25 GMT = 1556051005000 ミリ秒
- 2018 年 8 月 16 日午後 12:28:35 GMT = 1534422515000 ミリ秒
金額
この API の金銭的価値は「micros」という形式です。Google の標準となっています。micros は整数ベースの固定精度形式です。金額をマイクロ秒単位で表すには、標準の通貨値に 1,000,000 を掛けます。
例:
- 1.23 米ドル = 1230,000 マイクロ米ドル
- 0.01 米ドル = 10,000 マイクロ米ドル
べき等性
この API 内のすべてのメソッド呼び出しは、べき等の動作を持つ必要があります。Google は、トランザクションが両側で同じ状態になるように、リクエストを何度も再試行します。インテグレータは、すでに正常に処理されたリクエストを再処理しようとしないでください。代わりに、成功した処理のレスポンスを返す必要があります。すべてのメソッドには、requestId を含む共通の RequestHeader
があります。この requestId は、すべての呼び出しのべき等性のキーです。
非ターミナル レスポンス(HTTP 200 成功以外)は、べき等に処理してはいけません。したがって、以前に 400(不正なリクエスト/失敗した前提条件)を取得したリクエストは、2 回目の呼び出されたときにべき等に 400 を返さないようにする必要があります。再評価する必要があります。再評価時に 400 が返されるか、正常に処理される可能性があります。
べき等性の詳細については、こちらの詳細ガイドをご覧ください。
インテグレータ
Google の支払いプラットフォームをビジネスで使用している会社。YouTube や AdWords などの社内(1P)企業の場合もあれば、Google のエコシステムと連携させるために自社のサービスを統合したいと考えている社外(3P)企業もあります。
FOP
お支払い方法。これは、楽器というよりも一般的なものです。Visa、MasterCard、PayPal はすべて FOP です。
楽器
特定の顧客による支払い方法の特定のインスタンス。(ユーザーのクレジット カード、PayPal アカウントなど)。特定の顧客のトークン化された FOP も支払い方法の一つになります。これは、その顧客のお支払い方法のインスタンスであり、Google のシステムに安全に保存されているからです。
トークン
Google のシステムにおける特定のユーザーの支払い方法の表現。トークンには購入に必要なすべての情報が含まれているため、トークンでもあります。これには、ユーザーがインテグレータから入手した口座番号などの情報が含まれることがあります。
Key flows
Google uses two key flows to create and pay these reference numbers:
- Generate Reference Number Flow.
- Pay Reference Number Flow.
Later, reconciliation and settlement from resulting purchases are handled by the remittance flow.
The diagram below illustrates each of these flows.
Cash FOP overview
The first two flows are described in more detail in the following sections. See the Remittance flow page if you want to know more about that flow.
Generate reference number
The purpose of the generate reference number flow is to create and exchange an identifier (reference number) that both Google and the integrator can use to identify a purchase. The user can then use this reference number at a convenience store, kiosk, or bank to complete the purchase. This identifier is generated by the integrator at Google's request by calling the generateReferenceNumber
method. The request for generation of the reference number includes an amount and a transaction description.
The following diagram illustrates how a reference number is generated and sent to the customer with instructions.
Generate reference number flow
Here is a list of the objects and what they represent:
- User: This is the person who wants to pay for something using this form of payment.
- Google UI: This is the interface where the User makes their purchase. It could be through the web or through an app.
- Google Server: The backend server at Google that requests the generation of the reference number and creates payment instructions for the user.
- Payment Integrator Server: The backend server of the Payment Integrator that keeps track of the payment details and generates the reference number.
This flow begins with the user who wants to use this cash form of payment.
- The User accesses the Google UI which sends sends a request for a reference number.
- The Google UI sends a message to the Google Server that it needs a reference number (
getReferenceNumber
). - The Google Server asks the Payment Integrator Server to generate a reference number (
generateReferenceNumber
). - The Payment Integrator Server generates and sends the reference number to the Google Server.
- The Google Server creates payment instructions to go along with the reference number. Then it sends this information to the Google UI.
- The Google UI sends these instructions and reference number to the User.
Notes on reference numbers
Reference numbers can only be paid once, and they can be cancelled through the cancel reference number flow. Also, reference numbers must be alphanumeric, and it must support multiple display formats.
In addition to displaying the reference number, Google's UIs can optionally represent the reference number in the Code 128 format (a barcode format). Other barcode formats can be supported by request.
Pay Reference Number
The user will use this reference number at a convenience store, kiosk, or bank to identify the purchase the user wants to pay for. The integrator should have the user confirm the purchase being paid by displaying the purchase amount, date, and transaction description prior to paying.
Once the user chooses to pay, they must pay in full, and only pay once. This API does not support over or under payments on a single reference number. Multiple payments to a single reference number is also not supported.
Once the user pays, the integrator must immediately notify Google that this reference number has been paid via the
method. By calling this method within seconds of the user physically paying, the integrator allows the user to quickly receive their goods. (This call can be added to a queue if the network is down.)referenceNumberPaidNotification
Once paid, the reference number and amount will be included in the remittance statement sent on T+2 days.
Here is a sequence diagram that illustrates the payment of a reference number.
Pay reference number flow
The objects in the diagram represent the following:
- User: This is the person who wants to pay for something using this form of payment.
- Convenience Store: The location where the user makes their payment using the reference number and instructions given, such as a convenience store.
- Payment Integrator Server: The backend server of the Payment Integrator that keeps track of the payment details.
- Google Server: The backend server at Google that requests the generation of the reference number and creates payment instructions for the user.
This flow begins with the user who goes to a convenience store in order to make a payment according to the instructions given to them.
- The User goes to a Convenience Store to make a payment.
- After the transaction is complete, the convenience store notifies the payment integrator of payment.
- The Payment Integrator Server sends a success message to the Convenience Store.
- The Convenience Store conveys that the transaction was a success to the User, and the goods will be delivered to the User soon.
- The Payment Integrator Server sends a message to Google’s Server that the reference number has been paid (
). This step must not block step 4.referenceNumberPaidNotification
- The Google Server responds with a message of success to the Payment Integrator Server.
Cancel reference number
Reference numbers can be cancelled by Google. If Google cancels a reference number, the cancelReferenceNumber
method will be called. Upon successful return of this call, it is invalid to pay that reference number, and the integrator must refuse payment for this number. Upon success of this call, all future calls to the
will fail.referenceNumberPaidNotification
If the payment process has already started, for example if the user has entered their reference number into a kiosk but has not yet paid, the integrator should return a HTTP 423 response code with ErrorResponse containing [USER_ACTION_IN_PROGRESS
][google.standardpayments.v1.ErrorResponse].
Refund
Paid reference numbers can be refunded by Google using the request ID of the original generateReferenceNumber
call (note that refunds will NOT use the reference number). If Google refunds a reference number, the refund
method will be called. This method can be called multiple times with amounts totalling less than or equal to the original paid amount.
Next: Remittance flow