-
Notifications
You must be signed in to change notification settings - Fork 308
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.
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
SEP-38: add context
request parameter and fee
& total_price
response attributes
#1204
Conversation
…` request parameters, so anchors can calculate the quote taking into consideration what they will be used for. ([#????](https://github.com/stellar/stellar-protocol/pull/????))
…ters, so Anchors can detail the margin costs.
…unt_fee` and `amount_fee_asset` fields when a `quote_id` is used.
…nt_fee` and `amount_fee_asset` fields when a `quote_id` is used.
context
and fee_details
context
request parameter and fee_details
response parameter
@marcelosalloum I forgot to add a top-level comment so I'll do that here. Overall I think this is the right approach, although it seemed to be limiting the fees to only using the margin. I thought we had agreed to support additive / inclusive fees too, but I'm happy to discuss further. |
Since you're suggesting to support additive fees as part of SEP-38, should we enforce that SEP-31 amounts should be consistent with SEP-38's? For instance, |
…/fee mandatory for /price and /quote.
5423002
to
243c2f7
Compare
context
request parameter and fee_details
& effective_price
response parameterscontext
request parameter and fee
& effective_price
response parameters
context
request parameter and fee
& effective_price
response parameterscontext
request parameter and fee
& effective_price
response attributes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have one requested adjustment but otherwise this looks ready!
…eeds to be true only when `quote_id` is used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've asked @leighmcculloch to take a look, but if he is busy we can merge.
This PR doesn't communicate why this change is being made. Could you add that context? I'm specifically interested why applications need a |
Does this statement refer only to the fees that get added on, and not fees built into any rates? |
Good point! I've just updated the PR description. --
Yes, only refers to fees that appear under the |
Is "effective price" the best name we can give the price-inclusive-of-fees concept? A quick internet search revealed there is another concept named "effective exchange rate" which has different meaning. If there's not a better name sgtm, but I also don't see the effective on either of the screenshots, so maybe there's a better name we can use that will align with the existing money transfer industry? |
there's something called "out-the-door price" that has a similar meaning but is only used in the car selling business. I didn't really find a well known concept for this, so the options I have in mind are:
None of them seems great though, I'd continue with effective_price unless you guys think another option is clearly better. |
The only other decent option we have (in my opinion) is The important thing is that this attribute communicates the discrepancy between |
I would lean total price, given that the term total is used in at least one of the screenshots above. Effective has a non-specific sense to it for me, where-as the price being described is a concrete value. But I don't feel strongly, and in light of all the options effective also seems fine too. |
context
request parameter and fee
& effective_price
response attributescontext
request parameter and fee
& total_price
response attributes
…-protocol#1204 (#285) ### What Update platform code to be compliant with the protocol change added in stellar/stellar-protocol#1204 & stellar/stellar-anchor-platform#32. Changes in the SEP: * SEP-38 `GET /price` and `POST /quote` requests now need the new parameter `context=sep6|sep31`. * SEP-38 `GET /price` and `GET|POST /quote` responses now return the new parameters `total_price` and `fee`. Changes in the Platform->Anchor event schema: * The `QuoteEvent` schema contains 4 new parameters: `"fee"`, `"total_price"`, `"send_amount"` and `"buy_amount"` parameters. Changes in the Platform->Anchor `GET /rate` callback: * Update types from `["indicative", "firm"]` to `["indicative_prices", "indicative_price", "firm"]`. * Add the request parameter `"context=sep6|sep31"`, that should be mandatory for `["firm", "indicative_price"]` types. * Add `"fee"`, `"total_price"`, `"send_amount"` and `"buy_amount"` response parameters. ### Why Close #270, addressing the changes from stellar/stellar-protocol#1204 & stellar/stellar-anchor-platform#32.
### What Update SEP-38 tests based on stellar/stellar-protocol#1204. The changes include: * SEP-38 `GET /price` and `POST /quote` now require the mandatory `context` request parameter. * SEP-38 `GET /price` and `GET|POST /quote` now return the mandatory response parameters `total_price` and `fee`. * The updated formulas from [SEP38#price-formulas](https://github.com/stellar/stellar-protocol/blob/faa99165050dcd44a9e0f700c3d019258d8b4321/ecosystem/sep-0038.md#price-formulas) are now being validated.
What
Add the ability for SEP-38 quotes to detail the quote fees under the
fee
response field, and calculate the fees and price based on the input parametercontext
:context
is a mandatory request field and can be one ofsep6
orsep31
.total_price
is a new response field that describes the conversion rate with the fees included.price
will describe the conversion rate without including fees.GET /quote/:id
response will look like this:amount_fee
andamount_fee_details
, stating that it should be consistent with SEP-38fee_details
when provided.Why
Comparing the previous design with partners that have a long history in the currency conversion business we found out that it's pretty common to use not only margin but also additive/inclusive fees.
That's why we decided to change the SEP design, so we can be compliant with these businesses.
Regarding the inclusion of
"total_price"
, this was introduced so the conversion price and fees can be displayed to the user regardless of the remittance platform using additive or inclusive fees. For instance:Moneygram uses additive fees, so they use
price
only:wise.com uses inclusive fees, so they use
total_price
: