From cd08e42cb982bd1e0d3765cd0fe8d589fda2eedd Mon Sep 17 00:00:00 2001 From: jiahuihu Date: Mon, 7 Oct 2024 16:16:20 -0400 Subject: [PATCH] add methods to info response and update fields desc --- ecosystem/sep-0031.md | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/ecosystem/sep-0031.md b/ecosystem/sep-0031.md index adaee0045..70534818f 100644 --- a/ecosystem/sep-0031.md +++ b/ecosystem/sep-0031.md @@ -6,8 +6,8 @@ Title: Cross-Border Payments API Author: SDF Status: Active Created: 2020-04-07 -Updated: 2024-07-23 -Version 3.0.0 +Updated: 2024-10-07 +Version 3.1.0 ``` ## Simple Summary @@ -249,7 +249,7 @@ earlier than the quote's expiration. 1. If `error`, the Receiving Anchor should be contacted to resolve the situation. 1. If `pending_transaction_info_update`, the `transaction.fields` values collected from the Sending Client were invalid and must be corrected by the Sending Client. See the - [Pending Transaction Info Update](#pending-transaction-info-update) section for more information. + [Pending Transaction Info Update](#pending-transaction-info-update-deprecated) section for more information. 1. If `pending_customer_info_update`, the SEP-9 KYC values collected were invalid and must be corrected by the Sending Client. See the [Pending Customer Info Update](#pending-customer-info-update) section for more information. 1. After providing the Receiving Anchor with updated values, the status should ultimately change to `completed`. @@ -326,6 +326,13 @@ The response should be a JSON object like: "fee_percent": 1, "min_amount": 0.1, "max_amount": 1000, + "fields": { + "type": { + "description": "methods supported by the anchor for asset deposits", + "choices": ["SEPA", "SWIFT"], + "optional": false + } + }, "sep12": { "sender": { "types": { @@ -376,7 +383,7 @@ the corresponding off-chain asset, after fees have been applied. | `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 | (**deprecated**, optional) An object containing the per-transaction parameters required in `POST /transactions` requests. Pass [SEP-9] fields via [SEP-12 PUT /customer](sep-0012.md#customer-put) instead. | +| `fields` | object | (**deprecated**, optional) An object that contains multiple key-value pairs, where each key represents a field related to the transaction, and the value is an `transaction` object describing the field's details. | | `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. | @@ -400,9 +407,9 @@ the cases where no KYC is necessary. #### `fields` Object Schema -| Name | Type | Description | -| -------- | ------ | ---------------------------------------------- | -| `fields` | object | An object containing single `transaction` key. | +| Name | Type | Description | +| -------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `fields` | object | An object that contains multiple key-value pairs, where each key represents a field related to the transaction, and the value is an `transaction` object describing the field's details. | #### `transaction` Object Schema @@ -624,7 +631,7 @@ On success the response should include a `200 OK` HTTP status code and the follo - `pending_customer_info_update` -- certain pieces of information need to be updated by the Sending Anchor. See the [Pending Customer Info Update](#pending-customer-info-update) section for more information. - `pending_transaction_info_update` -- certain pieces of information need to be updated by the Sending Anchor. See the - [Pending Transaction Info Update](#pending-transaction-info-update) section for more information. + [Pending Transaction Info Update](#pending-transaction-info-update-deprecated) section for more information. - `pending_receiver` -- payment is being processed by the Receiving Anchor. - `pending_external` -- payment has been submitted to external network, but is not yet confirmed. - `completed` -- funds have been delivered to the Receiving Client. @@ -1040,7 +1047,8 @@ unexpected downtime, it is recommended to poll all in-progress transactions to f ## Changelog -- `v3.0.0`: Update SEP31 with async kyc flow ([#1502](https://github.com/stellar/stellar-protocol/pull/1502)) +- `v3.1.0`: Add methods to info response () +- `v3.0.0`: Update SEP-31 with async kyc flow ([#1502](https://github.com/stellar/stellar-protocol/pull/1502)) - `v2.6.0`: Add `fee_details` field to the transaction object ([#1429](https://github.com/stellar/stellar-protocol/pull/1429)) - `v2.5.0`: Deprecate and make optional the use of per-transaction `fields` objects