ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-06 17:27:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

[DOC] gws: first draft at actually defining a payment obj.

Browse Source
This commit is contained in:
mDuo13
2014-10-17 20:04:53 -07:00
parent a5b9750006
commit ad335133a2
1 changed files with 155 additions and 300 deletions
Download Patch File Download Diff File Expand all files Collapse all files

455
gateway_services_spec.md
View File

@@ -19,11 +19,24 @@ Gateways that implement these services can easily link with one another, allowin
# Gateway Services Identifiers #
Several APIs require you to identify the sender or recipient of a payment. Since several different types of identifiers can be used this way, Gateway Services defines a standard way to create a Universal Resource Identifier (URI) for each type of resource.
Several APIs require you to identify the sender or recipient of a payment. Since several different types of identifiers can be used this way, Gateway Services defines a standard way to create a Universal Resource Identifier (URI) for each type of resource. Any party of a payment should have a URI associated with it that can be WebFingered. This may include:
All of these resources map to either a Ripple account, an external account, or a human.
* The originator (sender) of a payment
* The beneficiary (receiver) of the payment
* Up to two gateways operating as inbound bridge and/or outbound bridges <span class='draft-comment'>(What kind of identifier should they use?)</span>
* Up to two "Participating parties" (one on each end of the transaction), for example the clerk at a store receiving or handing out cash. This may be important for compliance purposes, especially for remittance.
The following URI types should be supported:
As a general rule on the web at large, any URI starts with a "scheme" portion, followed by a colon, for example `http:`. Gateway service supports using URIs with several different schemes as identifiers to represent the parties to a payment. Depending on the scheme, a particular URI may map to something different:
* `acct:` identifiers refer to a user account at a particular service, such as an account at a bank or financial service.
* `ripple:` identifiers refer to a specific Ripple account in the shared global ledger
* Other identifiers can be used, depending on the configuration of the gateway being used.
An identifier can only be used if a JRD with the necessary information can be found by WebFingering that identifier. Part of the challenge is knowing which WebFinger service to use to look up the desired URI. This is a matter of finding out the right domain to use from the URI.
## Native Identifiers ##
Some kinds of URIs provide a single clear domain that can be used to perform the WebFinger request. A client application must use the following rules for where to WebFinger identifiers in the following formats:
| Type of Identifier | Example | Where to WebFinger |
|--------------------|---------|--------------------|
@@ -33,13 +46,21 @@ The following URI types should be supported:
| Ripple Address with Destination Tag | ripple:rBWay8KRdmroZra4DTXi6h5cLtPhs5mH7v?dt=103047 | Domain from the Ripple AccountRoot object |
| Ripple Name | ripple:bob | Domain from the Ripple AccountRoot object |
Legacy addresses - Where to webfinger **depends on the outbound bridge.** This is because the outbound bridge is bound only by trust to make the last mile of the payment, outside of the Ripple Ledger. The outbound bridge can be chosen in a few ways:
In the case where a particular email does not provide sufficient information to send a payment, client applications may optionally use a [WebFist](http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html) service to check for alternate places to WebFinger the provided address.
1. Client configuration - user explicitly chooses an outbound bridge to use (user takes responsibility for last mile)
* Client can make this easier by using a central "Registry" of outbound bridges and presenting choices to the user
2. Inbound bridge knows about outbound bridges it trusts (esp. ones operated by the same entity, e.g. Bitstamp trusts its own Bitcoin bridge)
## Additional Identifiers ##
<span class='draft-comment'>(Still TBD)</span>
Additional identifiers may be supported, in order to provide compatibility with other payment systems. Decide where to WebFinger additional URI formats according to the following rules:
Client Applications should either:
* Be explicitly linked to a particular gateway (e.g. a Fidor app that uses only Fidor-hosted Gateway Services), _or_
* Only WebFinger gateways explicitly chosen by the user.
* Client apps can make this easier by using a central "Registry" of gateways and presenting choices to the user. <span class='draft-comment'>No spec for such a registry exists at this time.</span>
Gateway Services providers can recursively WebFinger the **reciever** of a payment based on the **outbound bridges** it trusts that are capable of handing the **destination currency**. Gateways should take responsibility for the outbound bridges that they trust to make the last mile of a payment. This might mean only using outbound bridges that are operated by the same business entity or its partners.
As long as the identifier is reasonably likely to *uniquely* refer to a particular account or person, arbitrary identifiers may be used. We recommend specific formats for the following types of identifiers: <span class='draft-comment'>Format and examples are non-final mockups.</span>
| Type of Identifier | Format | Example |
|--------------------|---------|---------|
@@ -51,23 +72,36 @@ Legacy addresses - Where to webfinger **depends on the outbound bridge.** This i
| Google wallet | google:{email address} | google:mduo13@gmail.com |
| Square cash | square:{email address} | square:rome@ripple.com |
Participating Parties - neither the sender nor receiver, but information lookup for these parties is important for compliance purposes (e.g. clerk at a store receiving or handing out cash). <span class='draft-comment'>(acct:{email} or whatever)</span>
# Host-Meta #
Host-Meta tells you about things operated by a domain.
[RFC6415](http://tools.ietf.org/html/rfc6415) defines a standardized way to publish metadata, including information about resources controlled by the host, for any domain. In contrast to the original spec, **Ripple uses the JSON version of host-meta exclusively**, and never queries for the XML version. This spec defines several Ripple-centric resources which a host can advertise in a host-meta file, so that other applications can automatically **find** the host's other Gateway services, and **verify** the domain's various Ripple assets. This extends and replaces the functionality of the [ripple.txt](https://wiki.ripple.com/Ripple.txt) spec.
The response to a host-meta request is a document called a JRD (JSON resource descriptor; there is also an XML version called an XRD). You can retrieve a domain's host-meta JRD by making an HTTP GET request to the `/.well-known/host-meta.json` path at the top level of the domain. You can also GET `/.well-known/host-meta` while providing an `Accept: application/json` header. Hosts implementing Gateway Services should support both methods.
The response to a host-meta request is a document called a JRD (JSON resource descriptor; there is also an XML version called an XRD).
<span class='draft-comment'>
<div class='draft-comment'>
(Some things that aren't in host-meta but maybe should be:
- what inbound & outbound bridges this system operates
- what currencies those bridges take?
</span>
<ul><li> what inbound & outbound bridges this system operates</li>
<li> what currencies those bridges take?</li></ul>
</div>
#### Request Format ####
```
GET /.well-known/host-meta.json
```
Alternate request format:
```
GET /.well-known/host-meta
Accept: application/json
```
*Note:* Some domains that do not use Gateway Services may implement host-meta without providing a JRD. In this case, the alternate request format may return an XRD document instead of a Not Found error.
Here is an example of an entire host-meta JRD:
@@ -102,88 +136,9 @@ __`GET https://latambridgepay.com/.well-known/host-meta.json`__
"rel": "lrdd",
"template": "https://latambridgepay.com/.well-known/webfinger.json?q={uri}"
},
{
"rel": "https://gatewayd.org/gateway-services/bridge_payments/quotes",
"template": "https://latambridgepay.com/v1/bridge_payments/quotes/{receiver}/{amount}",
"properties": {
"version": "1"
}
},
{
"rel": "https://gatewayd.org/gateway-services/bridge_payments",
"href": "https://latambridgepay.com/v1/bridge_payments",
"properties": {
"version": "1",
"fields": {
"sender_claims": {
"bank": {
"type": "AstropayBankCode",
"required": true,
"label": {
"en": "Astropay Bank Code",
"es": "Astropay Código del banco"
},
"description": {
"en": "Bank code from Astropay's documentation"
}
},
"country": {
"type": "AstropayCountryCode",
"required": true,
"label": {
"en": "Astropay Country Code"
},
"description": {
"en": "Country code from Astropay's documentation"
}
},
"cpf": {
"type": "PersonalIDNumber",
"required": true,
"label": {
"en": "Personal Government ID Number"
},
"description": {
"en": "Personal ID number from the Astropay documentation"
}
},
"name": {
"type": "FullName",
"required": true,
"label": {
"en": "Sender's Full Name"
},
"description": {
"en": "First and last name of sender"
}
},
"email": {
"type": "EmailAddress",
"required": true,
"label": {
"en": "Sender's Email Address"
},
"description": {
"en": "Sender's Email Address"
}
},
"bdate": {
"type": "Date",
"required": true,
"label": {
"en": "YYYYMMDD"
},
"description": {
"en": "Sender's date of birth"
}
}
}
}
}
},
{
"rel": "https://gatewayd.org/gateway-services/bridge_payment_status",
"template": "https://latambridgepay.com/api/v1/bridge_payments/{id}",
"properties": {
"version": "1"
}
@@ -234,7 +189,7 @@ Ripple defines the following properties:
| rl:accounts | Array of objects | Each member of this array should be an [account definition object](#acct_def_obj) for an issuing account (cold wallet) operated by this host |
| rl:hotwallets | Array of strings | Each member of this array should be either a base-58-encoded Ripple Address or a Ripple Name for a hot wallet operated by the host |
(Ripple clients may also use the standard objects "name" and "description"
Gateway Services clients may also use the standard "name" and "description" properties.
#### Account Definition Object <a name="acct_def_obj"></a> ####
@@ -259,18 +214,18 @@ Example account definition object:
## Host-Meta Links ##
The `links` field contains links to almost anything, where the meaning of the link is programmatically identified by a relation type, typically a URI, in the `rel` field of the link object. Gateways should use links to advertise the other Gateway Services APIs that they offer.
The `links` field contains links to almost anything. The meaning of the link is identified by a relation type, typically a URI, in the `rel` field of the link object. Gateways should use links to advertise the other Gateway Services APIs that they offer.
Gateway Services requires the following links in host-meta:
* [Webfinger link](#webfinger_link)
* [Bridge Payments Get Quotes link](#bridge_quotes_link)
* [Bridge Payments Accept Quote link](#bridge_payments_link)
* [Bridge Payments Get Quote Status link](#bridge_payment_status_link)
* <span class='draft-comment'>(Additional services like user-account and wallet-info TBD?)</span>
* [Webfinger Link](#webfinger_link)
* [Bridge Payments Link](#bridge_payments_link)
* <span class='draft-comment'>(Additional services like user-account and wallet-info TBD)</span>
### Webfinger Link <a name="webfinger_link"></a> ###
### WebFinger Link <a name="webfinger_link"></a> ###
This link indicates where the [WebFinger (lrdd) service](#webfinger) is provided.
```js
...
@@ -289,84 +244,23 @@ Gateway Services requires the use of the [Webfinger protocol](https://code.googl
| rel | `lrdd` |
| template | The URL of your webfinger service, with `{uri}` in place of the resource to look up. |
For the details of how the Webfinger service itself should operate, see the [Gateway Services Webfinger Reference](#webfinger).
### Bridge Payments Link <a name="bridge_payments_link"></a> ###
### Bridge Payments: Get Quotes Link <a name="bridge_quotes_link"></a> ###
Also see the [Bridge-Quotes Reference](#bridge-quotes).
This link indicates where the [Bridge-Payments Service](#bridge-payments) is provided.
```js
...
"links": [
...
{
"rel": "https://gatewayd.org/gateway-services/bridge_quotes",
"template": "https://latambridgepay.com/v1/{sender}/bridge_payments/quotes/{receiver}/{amount}",
"properties": {
"version": "1"
}
},
...
```
The fields of the link are defined as follows:
| Field | Value |
|----------|--------|
| rel | `https://gatewayd.org/gateway-services/bridge_quotes` |
| template | The URL of your bridge-quotes service, with `{sender}` in place of the identifier to send from, `{receiver}` in place of the identifier to send to, and `{amount}` in the place of how much to send. |
| properties | Object with key-value map of properties for this link. |
#### Properties ####
The following properties should be provided:
| Field | Value |
|----------|--------|
| version | `"1"` for this version of the spec. |
### Bridge Payments: Accept Quote Link <a name="bridge_payments_link"></a> ###
```js
...
"links": [
...
{
"rel": "https://gatewayd.org/gateway-services/bridge_payments",
"href": "https://latambridgepay.com/v1/bridge_payments",
"properties": {
"version": "1",
"fields": {
"sender_claims": {
"bank": {
"type": "AstropayBankCode",
"required": true,
"label": {
"en": "Astropay Bank Code",
"es": "Astropay Código del banco"
},
"description": {
"en": "Bank code from Astropay's documentation"
}
},
"country": {
"type": "AstropayCountryCode",
"required": true,
"label": {
"en": "Astropay Country Code"
},
"description": {
"en": "Country code from Astropay's documentation"
}
},
...
}
}
"version": "1"
}
},
...
}
...
```
The fields of the link are defined as follows:
@@ -374,7 +268,7 @@ The fields of the link are defined as follows:
| Field | Value |
|----------|--------|
| rel | `https://gatewayd.org/gateway-services/bridge_payments` |
| <span class='draft-comment'>href</span> | The URL of your payments API. (No variable parameters in the URL) |
| href | The base URL of the gateway's bridge-payments service. |
| properties | Object with key-value map of properties for this link. |
#### Properties ####
@@ -384,53 +278,6 @@ The following properties should be provided:
| Field | Value |
|----------|--------|
| version | `"1"` for this version of the spec. |
| fields | Specification of body fields for this method. <span class='draft-comment'>(But only the ones that are customizeable?)</span> |
For Bridge Payment, the `fields` property should include a `sender_claims` object that defines all the sender claims that might be provided as sub-fields to the `sender_claims` object of a payment at the time of submission. Importantly, this includes a definition of which fields are required or optional. Each field should be defined by the following parameters:
| Field | Value | Description |
|----------|--------|-------------|
| type | String ([Sender Claims Types](#sender-claims-type-reference)) | What sort of data should go in this field. |
| required | Boolean | Whether or not this claim is required in order to send a payment. |
| label | Object | Map of brief labels for this field. Keys should be [two-character ISO-639.1 codes](http://www.loc.gov/standards/iso639-2/php/code_list.php), and values should be human-readable Unicode strings (in the corresponding language) suitable for display in a UI. |
| description | Object | Map of longer descriptions for this field. Keys should be [two-character ISO-639.1 codes](http://www.loc.gov/standards/iso639-2/php/code_list.php) <span class='draft-comment'>(or 3 letter codes instead? Any preferences?)</span>, and values should be human-readable Unicode strings (in the corresponding language) suitable for display in a UI. |
For the label and description fields, user-agent applications can choose which language to display, and which languages to fall back on in cases where the preferred language is not provided.
### Bridge Payments: Get Quote Status Link <a name="bridge_payment_status_link"></a> ###
```js
...
"links":
...
{
"rel": "https://gatewayd.org/gateway-services/bridge_payment_status",
"template": "https://latambridgepay.com/api/v1/bridge_payments/{id}",
"properties": {
"version": "1"
}
}
...
```
The fields of the link are defined as follows:
| Field | Value |
|----------|--------|
| rel | `https://gatewayd.org/gateway-services/bridge_payment_status` |
| template | The URL of your bridge-quotes service, with `{id}` in place of the payment to check |
| properties | Object with key-value map of properties for this link. |
#### Properties ####
The following properties should be provided:
| Field | Value |
|----------|--------|
| version | `"1"` for this version of the spec. |
# WebFinger #
@@ -482,18 +329,11 @@ __`GET https://latambridgepay.com/.well-known/webfinger?resource=ripple:bob`__
"ripple:rBWay8KRdmroZra4DTXi6h5cLtPhs5mH7v"
],
"links": [
{
"rel": "https://gatewayd.org/gateway-services/bridge_quotes",
"template": "https://latambridgepay.com/v1/{sender}/bridge_payments/quotes/{receiver}/amount",
"titles": {
"default": "Get quotes to send funds between Ripple and bank accounts in Latin America."
}
},
{
"rel": "https://gatewayd.org/gateway-services/bridge_payments",
"href": "https://latambridgepay.com/v1/bridge_payments",
"titles": {
"default": "Send funds between Ripple and bank accounts in Latin America."
"properties": {
"version": "1"
}
}
],
@@ -502,7 +342,7 @@ __`GET https://latambridgepay.com/.well-known/webfinger?resource=ripple:bob`__
```
### Webfinger Aliases <a id="webfinger_aliases"></a> ###
## Webfinger Aliases <a id="webfinger_aliases"></a> ##
The `aliases` field of a WebFinger document can contain various values, including ones that are not related to Ripple. Gateway Services defines three formats for aliases that refer to Ripple addresses:
@@ -516,8 +356,11 @@ The `aliases` field of a WebFinger document can contain various values, includin
A user can have any number of aliases of any combination of the above types, in addition to non-Ripple aliases, which clients of Gateway Services should ignore.
<span class='draft-comment'>(But what if we want to send money to an off-ledger account? Can we support a type of URI that's for receiving money?)</span>
### Webfinger Links <a id="webfinger_links"></a> ###
## Webfinger Links <a id="webfinger_links"></a> ##
<div class='draft-comment'>(Should we have only a link that matches the bridge-payments one, or one link that provides a URL specifically for getting a quote for a payment <em>to</em> this identifier? What about quotes for payments <em>from</em> this identifier? All of the above?
The `links` field of a WebFinger document should contain link elements describing where to find the following APIs:
@@ -528,15 +371,86 @@ Both of these should be specified exactly as in the host-meta, with the followin
* The `{receiver}` field of the Bridge Payments: Get Quotes `template` should be already filled-in with an appropriate URI based on the resource that was WebFingered.
* The `sender_claims` field of the Bridge Payments: Accept Quote `properties` may differ from the ones available in the host-meta, in case the WebFingered user has different required claims.
</div>
# Bridge Payments #
The Bridge Payments service consists of the following three API calls.
The URL for all the Bridge Payments calls is relative to the base URL defined in the [Host-Meta Bridge Payments Link](#bridge-payments-link). This should always include at least: `/v1/bridge_payments` (The v1 may change in future versions.)
* [Get Quotes - `GET /quotes/{sender}/{receiver}/{amount}`](#get-quotes)
* [Accept Quote - `POST /`](#accept-quote)
* [Check Status - `GET /{id}`](#check-status)
All three of these operate on a single type: the Bridge Payment object. This is like a contract, representing a chain of steps that complete the intended payment from a sender to a receiver. Get Quotes returns a list of objects representing payments that could potentially happen; accept quote selects one and fills in all the necessary details, indicating that the client intends for it to happen; and Check Status confirms whether a payment is planned, in progress, or complete.
A payment object looks like this:
```js
{
"gateway_tx_id": "9876",
"gateway_tx_type": "in",
"gateway_tx_state": "accepting",
"gateway_tx_message": "In the process of accepting this quote",
"expiration": "1311280970",
"ripple_invoice_id": "8765",
"sender": {
"uri": "bob@bob-way.com",
"bank_account": "073240754",
"routing_number": "23790832978",
"country": "USA",
"bank_name": "Example Bank USA"
},
"sending_amount": {
"amount": "5.125",
"currency": "USD"
},
"sender_claims": [..JWTs here..],
"destination": {
"uri": "acct:stefan@fidor.de",
},
"destination_amount": {
"amount": "5",
"currency": "USD",
"issuer": "r4tFZoa7Dk5nbEEaCeKQcY3rS5jGzkbn8a"
},
"destination_claims": [JWTs??],
"inbound_bridge": "https://snapswap.us/knox",
"outbound_bridge": "https://ripple.fidor.de",
//other participating parties/money handlers??
}
```
The fields are defined as follows:
| Field | Value | Description |
|--------------------|--------|-------------|
| gateway\_tx\_id | String | Arbitrary ID for this gateway payment. <span class='draft-comment'>(Probably an unsigned int? Limited character set?)</span> |
| gateway\_tx\_type | String | <span class='draft-comment'>(in/out depends on a perspective. Not all the calls have perspective as written.)</span> |
| gateway\_tx\_state | String | What state the payment is in. Valid states are: `"quote"`, `"accepting"`, `"invoice"`, `"in_progress"`, `"complete"`, and `"canceled"` <span class='draft-comment'>Discuss.</span> |
| gateway\_tx\_message | String | A human-readable string describing the state the transaction is in. <span class='draft-comment'>(Maybe remove this?)</span> |
| expiration | String | <span class='draft-comment'>Expiration time in, what, UNIX time seconds? Of the whole thing?</span> |
| ripple\_invoice\_id | String | Arbitrary ID that will be used as the `InvoiceID` field of the Ripple payment <span class='draft-comment'>(What's the case for having different IDs for this payment on-Ripple and off-Ripple?)</span> |
| sender\_amount | Object | <span class='draft-comment'>Not in example, but seems crucial.</span> |
| sender\_info | Object | Information about the sender. `uri` sub-field should match the sender from get-quotes URL. <span class='draft-comment'>Is this additional addressing info that may be necessary to make the payment? Do we need a corresponding receiver_info? Where do we define the fields?</span> |
| sender\_claims | Array | (Optional) Array of [JWTs](https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-28) that provide KYC information about the sender <span class='draft-comment'>(and/or receiver?)</span> for compliance purposes. Each token is signed by some authority and may contain multiple claims. |
| destination | Object | Info about the ultimate beneficiary of the payment. `uri` subfield is the receiver [URI](#gateway-services-uris) from the get-quotes URL |
| destination\_amount | Object | <span class='draft-comment'>(Looks like a Ripple amount, but may not always be so.)</span> |
| destination\_claims | Array | (Optional) <span class='draft-comment'>(Do we need claims for the one receiving the payment, too?)</span> |
## Get Quotes ##
Get Quotes tells you what your options are for making a payment.
__`GET https://latambridgepay.com/v1/{sender}/bridge_payments/quotes/{receiver}/{amount}`__
__`GET https://latambridgepay.com/v1/bridge_payments/quotes/{sender}/{receiver}/{amount}`__
This API should accept parameters that are formatted as follows:
@@ -544,7 +458,11 @@ This API should accept parameters that are formatted as follows:
|-----------|--------|------------|
| sender | A URL-encoded (%-escaped) [Gateway Services Identifier](#gateway-services-identifiers) | acct%3Abob%40ripple.com |
| receiver | A URL-encoded (%-escaped) [Gateway Services Identifier](#gateway-services-identifiers) | ripple%3AraLiCEoiYDN3aTw2ZnGmEVXWwYXWiAxR7n |
| amount | Decimal value, and 3-letter currency code <span class='draft-comment'>(Or hex code for say, GBI?)</span> for the currency, concatenated with a `+` | 10.99+USD |
| amount | Decimal value, and 3-letter currency code <span class='draft-comment'>(What about demurraging currencies/assets like GBI XAU?)</span> for the currency, concatenated with a `+` | 10.99+USD |
Get Quotes is intended to be a recursive process: if the Gateway Services provider does not know how to make an outgoing payment to the receiver in the specified currency, it can perform a Get Quotes call using another gateway that it trusts, then
<span class='draft-comment'>(How is that any different from the user querying the outbound gateway directly through a GWS client? Do the requests or the returned quotes look different?)</span>
### Get Quotes Response ###
@@ -553,68 +471,25 @@ This API should accept parameters that are formatted as follows:
{
"success": true,
"bridge_payments": [
{
"gateway_tx_id": "9876",
"gateway_tx_type": "in",
"gateway_tx_state": "quote",
"gateway_tx_message": "Inactive, must be posted.",
"destination_account": "acct:stefan@fidor.de",
"destination_amount": {
"amount": "5",
"currency": "USD",
"issuer": "r4tFZoa7Dk5nbEEaCeKQcY3rS5jGzkbn8a"
},
"ripple_invoice_id": "8765",
"sender_info": {
"bank_account": "",
"routing_number": "",
"country": "",
"bank_name": ""
},
"sender_claims": [],
"receiver_info": {
"postal_code": ""
},
"receiver_claims": []
}
... (array of Payment objects in quote state. TODO: finalize payment object and fill in)
]
}
```
sender_info: additional addressing info that may be necessary to make the payment.
## Accept Quote ##
Bridge Payments lets you tell the gateway which payment you are making, so it can be ready.
```
POST https://latambridgepay.com/v1/bob%40ripple.com/bridge_payments
POST https://latambridgepay.com/v1/bridge_payments/bob%40ripple.com
{
"gateway_tx_id": "9876",
"gateway_tx_type": "in",
"gateway_tx_state": "quote",
"gateway_tx_message": "Inactive, must be posted.",
"destination_account": "acct:stefan@fidor.de",
"destination_amount": {
"amount": "5",
"currency": "USD",
"issuer": "r4tFZoa7Dk5nbEEaCeKQcY3rS5jGzkbn8a"
},
"ripple_invoice_id": "8765",
"sender_info": { //Bob suggests signing this?
"bank_account": "073240754",
"routing_number": "23790832978",
"country": "USA",
"bank_name": "Example Bank USA"
},
"sender_claims": [..JWTs here..]
}
(body is a payment object in "accepting" state. TODO: finalize payment object and fill in)
```
No URL parameters. The request body is one of the objects from the `bridge_payments` field of the [Bridge Quotes Response](#bridge-quotes-response), with all the sender claims filled in, as necessary.
<span class='draft-comment'>(Some problems with the body here - does it really make sense to include gateway\_tx\_state, etc.? What's the difference between gateway\_tx\_id and ripple\_invoice\_id?)</span>
<span class='draft-comment'>(Some problems with the body here - does it really make sense to include gateway\_tx\_state, etc.? What's the difference between gateway\_tx\_id and ripple\_invoice\_id? Shouldn't sender amounts be included?)</span>
@@ -646,30 +521,10 @@ Bridge payment status checks tells you whether a payment has happened yet.
__`GET https://latambridgepay.com/v1/bridge_payments/9876`__
<span class='draft-comment'>(This should also reflect any changes we make to the payment object.)</span>
Response:
```js
{
"success": true,
"bridge_payment": {
"gateway_tx_id": "9876",
"gateway_tx_type": "in", // in to ripple
"gateway_tx_state": "invoice",
"gateway_tx_message": "Invoice, must be paid.",
"expiration": "1311280970"
"destination_account": "acct:stefan@fidor.de",
"destination_amount": {
"amount": "5",
"currency": "USD",
"issuer": "r4tFZoa7Dk5nbEEaCeKQcY3rS5jGzkbn8a"
},
"ripple_invoice_id": "8765", <== Add invoice_id column to ripple_transactions
"sender_claims": {
"bank_account": "somebankaccount",
"routing_number": "routingnumber",
"country": "countrt",
"bank_name": "bankname"
}
}
}
(payment object. TODO: finalize payment object and fill in)
```