Overview
Remittance is when money is transferred from one party to another. One example might be when money sent from the Payment Integrator’s Bank to Google’s Bank. The following diagram illustrates how this occurs.
How the flow works
The following diagram illustrates one example of how the remittance flow could work.
Remittance Payment Integrator to Google
Here is a list of objects used in this diagram:
- Google Server: The backend server at Google that does the authentication check, along with other authentication tasks.
- Payment Integrator: The company that offers a form of payment to its customers.
- Payment Integrator Bank: The issuing bank that the Integrator uses for financial transactions.
- Google Bank: The bank that Google uses in transactions.
The remittance flow above begins with Google’s Server.
- On T+N days, Google sends the remittance statement notification (
remittanceStatementNotification). - The Payment Integrator notifies the Google Server that they have successfully received the remittance statement notification.
- The Payment Integrator also sends details of the remittance statement (
remittanceStatementDetails). - Google’s Server responds with the statement along with the transactionDetails.
- The Payment Integrator reconciles the details.
- The Payment Integrator sends a message (
acceptRemittanceStatement) to the Google Server that the statement has been accepted. - The Payment Integrator also sends a message that the Payment Integrator Bank should send funds to the Google Bank.
- The Payment Integrator’s Bank transfers funds to the Google Bank.
Best practices and other considerations
Timing
Payment terms are set out in the contract and typically expressed as T+N. T is the frequency that a remittance statement is generated and the length of the period that each statement covers. In the following example, T is one transaction day. N is the number of days after the transaction period that the remittance statement arrives.
If N is configured to be 2 and a transaction is accounted for at 23:59:59.999 in the billing time zone on Tuesday, it will show up in a statement on Thursday.
Net Negative or Zero Statements
For days where there are no transactions within the billing period, remittance statement notifications will not be sent. Further, if there are refunds within a billing period that results in a net negative invoice amount, remittance statements will also not be sent. These transactions will however be rolled into the next net positive invoice, for which the remittance statement notification will be sent. In the event that transaction amounts net to 0 for a particular billing period, remittance statement notifications will be sent.
Boundaries
Below are some examples with various boundaries. A transactional boundary is when the transaction starts or is committed. Remember, the accounting timestamp is when Google has accounted for this transaction. A remittance statement boundary starts at 00:00:00.000 and ends at 23:59:59.000.
Transaction Within Boundaries
| Event | |
|---|---|
| Capture | requestHeader.requestId
001 requestHeader.requestTimestamp 01/01/2017 23:26:32.253 responseHeader.responseTimestamp 01/01/2017 23:26:34.248 accounting timestamp 01/01/2017 23:26:34.781 |
| RemittanceStatementNotification | requestHeader.requestTimestamp
01/03/2017 03:17:18.132 billingPeriod.startDate 01/01/2017 00:00:00.000 billingPeriod.endDate 01/01/2017 23:59:59.999 This remittance notification includes capture 001 above. |
Transaction Spanning Boundaries
One of the captures below has all timestamps on 01/01/2017, however it isn't accounted for until 01/02/2017.
| Event | |
|---|---|
| Capture | requestHeader.requestId
001 requestHeader.requestTimestamp 01/01/2017 23:26:32.253 responseHeader.responseTimestamp 01/01/2017 23:26:34.248 accounting timestamp 01/01/2017 23:26:34.781 |
| Capture | requestHeader.requestId
002 requestHeader.requestTimestamp 01/01/2017 23:59:58.253 responseHeader.responseTimestamp 01/01/2017 23:59:59.879 accounting timestamp 01/02/2017 00:00:00.002 |
| RemittanceStatementNotification | requestHeader.requestTimestamp
01/03/2017 03:17:18.132 billingPeriod.startDate 01/01/2017 00:00:00.000 billingPeriod.endDate 01/01/2017 23:59:59.999 This remittance notification includes only capture 001. |
| RemittanceStatementNotification | requestHeader.requestTimestamp
01/03/2017 00:27:34.321 billingPeriod.startDate 01/02/2017 00:00:00.000 billingPeriod.endDate 01/02/2017 23:59:59.999 This remittance notification includes capture 002. Since 002 was accounted for on 01/02/2017, not 01/01/2017. |
Reconciliation
There may be cases where Google sends a remittance statement later than you expect. For example, if Google encounters a bug that delays the remittance statement notification by a day.
If there are transactions returned by the remittanceStatementDetails method that the integrator does not have within the billing period, the integrator should notify Google of the discrepancy immediately. Another possibility would be if there are transactions the integrator expects but are not returned. Once a discrepancy is resolved, Google may send a new remittance statement with a new ID.
Remittance Statement Acceptance
A statement is said to be accepted by the integrator once the integrator calls the acceptRemittanceStatement method.
Statements should be paid within the NET terms defined in the contract after acceptance. Disputes should be handled manually between the integrator and the account manager.
Payment
Remittance statements provide the necessary details on the amount to be paid. Each statement must be paid in full. If there is a disparity, the integrator must reach out to their account manager to handle the dispute. Such cases may result in not paying a statement in full.
Precision
Each fee will be calculated to the precision defined as the number of minor units specified in the ISO 4217 standard for that currency. For example, INR & USD will use 2 digit minor units and JPY will use 0 digit minor units.
If more decimal places are needed to represent the fee, Google will round to the nearest minor unit; ties will be rounded to the nearest even minor unit. For example using INR's 2 digit minor units:
| Computed fee | Rounded fee |
|---|---|
| 0.013 | 0.01 |
| 0.015 | 0.02 |
| 0.025 | 0.02 |
| -0.013 | -0.01 |
| -0.025 | -0.02 |
This rounding will happen on every transaction, not in aggregate on the statement.