SEP-31, 24, & 6: add optional refund_memo to transaction initiation requests
#1321
Conversation
|
cc @Nopik |
|
If we agree on this design (cc @marcelosalloum) then I will make the same changes to SEP-24 & SEP-6 |
There was a problem hiding this comment.
LGTM!
Please, don't forget to update the Changelog section at the bottom of the file.
ecosystem/sep-0031.md
Outdated
| `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. | ||
| `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. |
There was a problem hiding this comment.
🤔 Should anchors use a default value for the memo type? I mean, if the user sends a memo but no memo type, should it be considered a text memo?
There was a problem hiding this comment.
If we do want to standardize a default type, it should probably be id. That way the ecosystem could migrate to using muxed account addresses for refunds eventually.
But I don't know if providing a default makes sense. Maybe I should just add a clause to the definitions saying refund_memo and refund_memo_type must be sent together.
There was a problem hiding this comment.
But I don't know if providing a default makes sense. Maybe I should just add a clause to the definitions saying
refund_memoandrefund_memo_typemust be sent together.
Yeah, that makes sense to me.
JakeUrban
dismissed stale reviews from marcelosalloum and lijamie98
via
b99dc9b
JakeUrban
changed the title
refund_memo to POST /transactions requestrefund_memo to POST /transactions request
JakeUrban
changed the title
refund_memo to POST /transactions requestrefund_memo to transaction initiation requests
| Updated: 2022-11-18 | ||
| Version 2.7.0 |
There was a problem hiding this comment.
I think this should be 2.8.0, right?
|
|
||
| * `v2.7.0`: Add `refund_memo` and `refund_memo_type` parameters to withdraw endpoint. ([#1321](https://github.com/stellar/stellar-protocol/pull/1321)) |
There was a problem hiding this comment.
I think this should be 2.8.0, right?
I believe you forget to add the 2.7.0 changelog in #1320
There was a problem hiding this comment.
I think I messed up by actually incrementing the minor version on SEP-24 instead of the patch version. So 2.7 makes sense for this change.
Receiving anchors often use custodial services to hold their on-chain assets, and these custodians often use omnibus accounts, so memos are used by the custodian to map inbound payments to their customer's balances.
To support this case, the standard allows Receiving anchors to provide a memo & memo type to use for each transaction in the
POST /transactionsrequest.Sending anchors may also use custodial services to hold their on-chain assets, so in the event that a refund payment is necessary, sending anchors should be allowed to provide the receiving anchor a memo to use.
Thats why I'm adding two optional parameter to the
POST /transactionsrequest body, allowing the sending anchor to provide the receiving anchor with a memo to use when sending refund payments back.