Skip to content

Commit

Permalink
SEP-31: deprecate per-transaction fields (#1387)
Browse files Browse the repository at this point in the history
  • Loading branch information
@JakeUrban
JakeUrban authored Aug 31, 2023
1 parent 142afff commit c42f693
Showing 1 changed file with 12 additions and 49 deletions.
61 changes: 12 additions & 49 deletions ecosystem/sep-0031.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ Title: Cross-Border Payments API
Author: SDF
Status: Active
Created: 2020-04-07
Updated: 2023-01-13
Version 2.4.0
Updated: 2023-08-31
Version 2.5.0
```

## Simple Summary
Expand Down Expand Up @@ -272,23 +272,6 @@ The response should be a JSON object like:
}
}
}
},
"fields":{
"transaction":{
"receiver_routing_number":{
"description": "routing number of the destination bank account"
},
"receiver_account_number":{
"description": "bank account number of the destination"
},
"type":{
"description": "type of deposit to make",
"choices": [
"SEPA",
"SWIFT"
]
}
}
}
}
}
Expand All @@ -310,7 +293,7 @@ Name | Type | Description
`fee_percent` | number |(optional) A percentage fee in percentage points. Leave blank if there is no fee or fee calculation cannot be modeled using a fixed and percentage fee.
`sender_sep12_type` | string | (**deprecated**, optional) The value of the `type` parameter the Sending Anchor should use for a `SEP-12 GET /customer` request. This field can be omitted if no KYC is necessary. Use a value from `sep12.sender.types` instead if any are present.
`receiver_sep12_type` | string | (**deprecated**, optional) The value of the `type` parameter the Sending Anchor should use for a `SEP-12 GET /customer` request. This field can be omitted if no KYC is necessary. Use a values from `sep12.receiver.types` instead if any are present.
`fields` | object | An object containing the per-transaction parameters required in `POST /transactions` requests.
`fields` | object | (**deprecated**, optional) An object containing the per-transaction parameters required in `POST /transactions` requests. Pass [SEP-9](sep-0009.md) fields via [SEP-12 PUT /customer](sep-0012.md#customer-put) instead.
`quotes_supported` | boolean | (optional) If true, the Receiving Anchor can deliver the off-chain assets listed in the [`SEP-38 GET /prices`](sep-0038.md#get-prices) response in exchange for receiving the Stellar asset.
`quotes_required` | boolean | (optional) If true, the Receiving Anchor can only deliver an off-chain asset listed in the [`SEP-38 GET /prices`](sep-0038.md#get-prices) response in exchange for receiving the Stellar asset.

Expand Down Expand Up @@ -360,14 +343,7 @@ Content-Type: application/json
"asset_code": "USDC",
"asset_issuer": "GDRHDSTZ4PK6VI3WL224XBJFEB6CUXQESTQPXYIB3KGITRLL7XVE4NWV",
"sender_id": "d2bd1412-e2f6-4047-ad70-a1a2f133b25c",
"receiver_id": "137938d4-43a7-4252-a452-842adcee474c",
"fields": {
"transaction": {
"receiver_routing_number": "442928834",
"receiver_account_number": "0029483242",
"type": "SEPA"
}
}
"receiver_id": "137938d4-43a7-4252-a452-842adcee474c"
}
```

Expand All @@ -387,14 +363,7 @@ Content-Type: application/json
"asset_issuer": "GDRHDSTZ4PK6VI3WL224XBJFEB6CUXQESTQPXYIB3KGITRLL7XVE4NWV",
"destination_asset": "iso4217:BRL",
"sender_id": "d2bd1412-e2f6-4047-ad70-a1a2f133b25c",
"receiver_id": "137938d4-43a7-4252-a452-842adcee474c",
"fields": {
"transaction": {
"receiver_routing_number": "442928834",
"receiver_account_number": "0029483242",
"type": "SEPA"
}
}
"receiver_id": "137938d4-43a7-4252-a452-842adcee474c"
}
```

Expand All @@ -413,14 +382,7 @@ Content-Type: application/json
"destination_asset": "iso4217:BRL",
"quote_id": "2bc5b322-5117-413f-869f-e7ca494cb1a4",
"sender_id": "d2bd1412-e2f6-4047-ad70-a1a2f133b25c",
"receiver_id": "137938d4-43a7-4252-a452-842adcee474c",
"fields": {
"transaction": {
"receiver_routing_number": "442928834",
"receiver_account_number": "0029483242",
"type": "SEPA"
}
}
"receiver_id": "137938d4-43a7-4252-a452-842adcee474c"
}
```

Expand All @@ -435,7 +397,7 @@ Name | Type | Description
`quote_id` | string | (optional) The `id` returned from a `SEP-38 POST /quote` response. If this attribute is specified, the values for the fields defined above must match the values associated with the quote.
`sender_id` | `string` | (optional) The ID included in the [SEP-12 PUT /customer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-put) response for the Sending Client. Required if the Receiving Anchor requires SEP-12 KYC on the Sending Client.
`receiver_id` | `string` | (optional) The ID included in the [SEP-12 PUT /customer](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0012.md#customer-put) response for the Receiving Client. Required if the Receiving Anchor requires SEP-12 KYC on the Receiving Client.
`fields` | object | An object containing the values requested by the Receiving Anchor in the `GET /info` endpoint.
`fields` | object | (**deprecated**, optional) An object containing the values requested by the Receiving Anchor in the `GET /info` endpoint. Pass [SEP-9](sep-0009.md) fields via [SEP-12 PUT /customer](sep-0012.md#customer-put) instead.
`lang` | string | (optional) Defaults to `en`. Language code specified using [ISO 639-1](https://en.wikipedia.org/wiki/ISO_639-1). Any human-readable error codes or field descriptions will be returned in this language.
`refund_memo` | (optional) The memo the Receiving Anchor must use when sending refund payments back to the Sending Anchor. If not specified, the Receiving Anchor should use the same memo the Sending Anchor used to send the original payment. If specified, `refund_memo_type` must also be specified.
`refund_memo_type` | (optional) The type of the `refund_memo`. Can be `id`, `text`, or `hash`. See the [memos](https://developers.stellar.org/docs/encyclopedia/memos) documentation for more information. If specified, `refund_memo` must also be specified.
Expand Down Expand Up @@ -757,13 +719,13 @@ If the transaction cannot be found, the endpoint should return a `404 NOT FOUND`

In certain cases the Receiving Anchor might need to request updated information from the Sending Anchor. For example, if the bank tells the Receiving Anchor that the provided Receiving Client's name is incorrect or missing a middle initial. Since this information was sent via SEP-12, the transaction should go into the `pending_customer_info_update` state until the Sending Anchor makes another `SEP-12 PUT /customer` request to update. The Sending Anchor can check which fields need to be updated by making a `SEP-12 GET /customer` request including the `id` or `account` & `memo` parameters. The Receiving Anchor should respond with a `NEEDS_INFO` status and `last_name` included in the fields described.

#### Pending Transaction Info Update
#### Pending Transaction Info Update (Deprecated)

Another possibility is that the per-transaction information provided in the `POST /transactions` `fields` object was later discovered to be invalid. In this case, the transaction should go into the `pending_transaction_info_update` state until the Sending Anchor makes a request to the endpoint outlined below.
Another possibility is that the per-transaction information provided in the `POST /transactions` `fields` object was later discovered to be invalid. In this case, the transaction should go into the `pending_transaction_info_update` state until the Sending Anchor makes a request to the endpoint outlined below. This approach is deprecated in favor of using per-customer fields provided via [SEP-9](sep-0009.md) fields in [SEP-12 PUT /customer](sep-0012.md#customer-put) requests.

### PATCH Transaction
### PATCH Transaction (Deprecated)

This endpoint should only be used when the Receiving Anchor needs more info via the `pending_transaction_info_update` status from the Sending Anchor. The `required_info_updates` transaction field should contain the fields required for the update. If the Sending Anchor tries to update at a time when no info is requested, the Receiving Anchor should fail with an error response.
This endpoint should only be used when the Receiving Anchor needs more info via the `pending_transaction_info_update` status from the Sending Anchor. The `required_info_updates` transaction field should contain the fields required for the update. If the Sending Anchor tries to update at a time when no info is requested, the Receiving Anchor should fail with an error response. This approach is deprecated in favor of using per-customer fields provided via [SEP-9](sep-0009.md) fields in [SEP-12 PUT /customer](sep-0012.md#customer-put) requests.

```
PATCH DIRECT_PAYMENT_SERVER/transactions/:id
Expand Down Expand Up @@ -900,6 +862,7 @@ It is important to note that the Receiving Anchor is not obligated, at least by

## Changelog

* `v2.5.0`: Deprecate and make optional the use of per-transaction `fields` objects ([#1387](https://github.com/stellar/stellar-protocol/pull/1387))
* `v2.4.0`: Add `updated_at` to `GET /transactions/:id` response ([#1336](https://github.com/stellar/stellar-protocol/pull/1336))
* `v2.3.1`: Allow anchors to omit the deprecated `X-Stellar-Signature` header ([#1335](https://github.com/stellar/stellar-protocol/pull/1335))
* `v2.3.0`: Deprecate `X-Stellar-Signature` in favor of `Signature` ([#1333](https://github.com/stellar/stellar-protocol/pull/1333))
Expand Down

0 comments on commit c42f693

Please sign in to comment.