Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[SEP-31] Add methods to info response and update fields desc #1560

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

[SEP-31] Add methods to info response and update fields desc #1560

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 17 additions & 9 deletions ecosystem/sep-0031.md
View file
Open in desktop
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: 2024-07-23
Version 3.0.0
Updated: 2024-10-07
Version 3.1.0
```

## Simple Summary
Expand Down Expand Up @@ -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`.
Expand Down Expand Up @@ -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": {
Expand Down Expand Up @@ -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. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are adding type to fields, I think we should remove deprecated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neither of these descriptions quite make sense. The original version of the fields object schema looked like this:

{
  "fields": {
    "transaction": {}
  }
}

We deprecated fields because its only purpose was for transaction to specify request parameters required to be sent in POST /transactions requests.

Now that we're adding type, I think we have a couple options:

  • Deprecate fields.transaction specifically, and un-deprecated fields. This way we can add the type key to the fields object:
{
  "fields": {
    "type": {
      "description": "",
      "choices": [],
      "optional"
    }
  }
}
  • Un-deprecate both fields and field.transaction, and add type as a subfield of field.transactions:
{
  "fields": {
    "transaction": {
      "type": {
        "description": "",
        "choices": [],
        "optional"
      }
    }
  }
}

| `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 All @@ -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

Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down
Loading