feat(tipping): honour the recipient's minimum on the tip that opens a DM - #693
Merged
Conversation
A user can set a fee to be written to, but nothing on iOS read it — every
tip was measured against the server's regional preset instead. The fee buys
the conversation, so it applies to exactly one payment: the tip that opens
the DM.
entry | no DM yet | DM exists
-----------|--------------------------------------|-----------------
in-chat | recipient's fee, preset if they | no minimum
| charge none |
tip card | recipient's fee | system minimum
`TipFloor` holds the two floors and enforces the one it was handed, at
display precision. `SendAmountViewModel.opensTipDM` decides which applies,
using the rule `ConversationScreen.chatExists` already draws for a tip DM —
the feed holding the locally-derived id — so no network call is added.
Two consequences follow. The swipe reads "Swipe to Tip" only for the opening
payment and reverts to "Swipe to Send" afterwards. A preset chip below the
floor is not offered, and `selectedAmount` re-checks it, because the
recipient's fee resolves after the sheet is already up.
A fee is restated in the entry currency through USD, the way the rate table
is keyed. When either leg has no rate it falls back to the regional preset
rather than state a floor in a currency the entry isn't using.
Ports code-android-app#1366.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A user can set a fee to be written to, but nothing on iOS read it — every tip was measured against the server's regional preset instead. The fee buys the conversation, so it applies to exactly one payment: the tip that opens the DM.
TipFloorholds the two floors — the recipient's fee and the server's regional preset — and enforces the one it was handed, comparing at display precision.SendAmountViewModel.opensTipDMdecides which applies, using the ruleConversationScreen.chatExistsalready draws for a tip DM: the feed holding the locally-derived id. That keeps the decision in one place and adds no network call. The recipient's profile comes from the cache at init, with a best-effort fetch for the in-chat path, which — unlike the tip card path — has no resolved card to have cached one.Two consequences follow from the rule:
TipFlow.selectedAmountre-checks it, because the recipient's fee resolves after the sheet is already up and a chip never passes through the amount entry.A fee is restated in the entry currency through USD, the way the rate table is keyed. When either leg has no rate it falls back to the regional preset rather than state a floor in a currency the entry isn't using.
No copy changed — code-android-app#1366 moved Android's wording onto what iOS already shows.
Ports code-payments/code-android-app#1366.