- HTTP request
- Request body
- Response body
- SimulateTransferFundsResponse
- SimulateTransferFundsResult
- SuccessDetails
- AlternateFunds
- Decimal
Initiates a request to simulate a transfer from an account associated by the association ID for a given amount provided in the request. The return value contains the payment simulation result for the transaction.
If the endpoint encounters an error while processing the request, the response body from this endpoint should be of type
.ErrorResponse
An example request looks like:
{
"requestHeader": {
"protocolVersion": {
"major": 1,
"minor": 0,
"revision": 0
},
"requestId": "liUrreQY233839dfFFb24gaQM",
"requestTimestamp": "1502220434778"
},
"associationId": "LmddbXBsZSByZWZlcmVuY2UgdG9rZW4gdmFsdWU_",
"amount": {
"amountMicros": "728000000",
"currencyCode": "INR"
}
}
An example response looks like:
{
"responseHeader": {
"responseTimestamp": "1481900013178"
},
"result": {
"successWithAlternateFunds": {
"currentBalance": {
"amountMicros": 5000000,
"currencyCode": "MYR"
},
"alternateFunds": [
{
"description": "ChiliPoints",
"value": {
"value": "120"
},
"equivalentMonetaryValue": {
"amountMicros": 1000,
"currencyCode": "MYR"
}
}
]
}
}
}
HTTP request
POST https://www.integratorhost.example.com/integrator-base-path/e-wallets-v1/simulateTransferFunds
Request body
The request body contains data with the following structure:
JSON representation |
---|
{ "requestHeader": { object ( |
Fields | |
---|---|
request |
REQUIRED: Common header for all requests. |
association |
REQUIRED: The associationId of the user's account, originally provided in the |
amount |
REQUIRED: The transaction amount to evaluate. |
Response body
This method supports multiple return types. For additional information about what 4XX or 5XX HTTP status code to return with an ErrorResponse
, consult the ErrorResponse
object and HTTP status codes documentation.
Possible response messages | |
---|---|
HTTP 200 Status |
|
HTTP 4XX / 5XX Status |
|
SimulateTransferFundsResponse
Response object for the payment integrator hosted e-wallets-v1.simulateTransferFunds method.
JSON representation |
---|
{ "responseHeader": { object ( |
Fields | |
---|---|
response |
REQUIRED: Common header for all responses. |
result |
REQUIRED: The result of the e-wallets-v1.simulateTransferFunds call. |
SimulateTransferFundsResult
Result codes for e-wallets-v1.simulateTransferFunds
.
JSON representation |
---|
{ // Union field |
Fields | |
---|---|
Union field
|
|
success |
Successful transfer. |
success |
Successful transfer with alternate funding sources. |
insufficient |
This account does not have sufficient funds to guarantee this transfer. Based on the remedyMethod user will be recommended for top-up. |
charge |
This transfer request's |
charge |
This account cannot be used for transfers right now as it has exceeded its daily limits. |
charge |
This account cannot be used for transfers right now as it has exceeded its monthly limits. |
charge |
This transfer request's |
account |
This account does not support the requested currency. |
account |
The user's account held with the integrator has been closed. Returning this value will cause the user's instrument to be closed with Google. The user will be forced to add a new instrument by going through the association flow again. |
account |
The user's account with the integrator has been closed, suspected account take over. Returning this value will cause the user's instrument to be closed with Google. The user will be forced to add a new instrument by going through the association flow again. |
account |
The account is on hold. |
account |
The user's account held with the integrator has been closed because of fraud. Returning this value will cause the user's instrument to be closed with Google. The user will be forced to add a new instrument by going through the association flow again. |
google |
The account is active, but the GPT has been invalidated by the user on the integrator's side. Returning this value will cause the user's instrument to be closed with Google. The user will be forced to add a new instrument by going through the association flow again. |
SuccessDetails
Success details for e-wallets-v1.simulateTransferFunds
.
JSON representation |
---|
{ "currentBalance": { object ( |
Fields | |
---|---|
current |
OPTIONAL: This is the current available balance for the account. If provided, this value will be included in user-facing messaging. |
alternate |
OPTIONAL: Funding source information provided by the integrator, for example if or how the transaction could be partially funded by alternate sources. |
AlternateFunds
JSON representation |
---|
{ "description": string, "value": { object ( |
Fields | |
---|---|
description |
REQUIRED: This is the label that describes the funding source, for example "Auto top-up" or "InvisiPoints". |
value |
OPTIONAL: This is the value of the funding source. |
equivalent |
OPTIONAL: This is the monetary value equivalent to the alternate funds used. |
Decimal
A representation of a decimal value, such as 2.5. Clients may convert values into language-native decimal formats, such as Java's [BigDecimal][] or Python's [decimal.Decimal][].
[BigDecimal]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/math/BigDecimal.html [decimal.Decimal]: https://docs.python.org/3/library/decimal.html
JSON representation |
---|
{ "value": string } |
Fields | |
---|---|
value |
The decimal value, as a string. The string representation consists of an optional sign, The fraction consists of a decimal point followed by zero or more decimal digits. The string must contain at least one digit in either the integer or the fraction. The number formed by the sign, the integer and the fraction is referred to as the significand. The exponent consists of the character Services should normalize decimal values before storing them by:
Services may perform additional normalization based on its own needs and the internal decimal implementation selected, such as shifting the decimal point and exponent value together (example: Note that only the The ENBF grammar is:
Services should clearly document the range of supported values, the maximum supported precision (total number of digits), and, if applicable, the scale (number of digits after the decimal point), as well as how it behaves when receiving out-of-bounds values. Services may choose to accept values passed as input even when the value has a higher precision or scale than the service supports, and should round the value to fit the supported scale. Alternatively, the service may error with Services should error with |