Skip to content

feat(tipping): honour the recipient's minimum on the tip that opens a DM - #1366

Merged
bmc08gt merged 3 commits into
code/cashfrom
feat/tip-minimum-recipient
Aug 28, 2026
Merged

feat(tipping): honour the recipient's minimum on the tip that opens a DM#1366
bmc08gt merged 3 commits into
code/cashfrom
feat/tip-minimum-recipient

Conversation

@bmc08gt

@bmc08gt bmc08gt commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

#1360 let a user set the fee another person pays to open a DM with them (UserProfile.minDmChatInitFee), but no amount entry read it. Both the in-chat entry from #1362 and the tip card floored at the server's regional preset, so a tip under the recipient's own minimum was accepted locally and rejected on send.

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, tip DM recipient's fee (regional preset if they charge none) no minimum
in-chat, contact DM none none
tip card / custom amount recipient's fee system minimum

TipPaymentDelegate owns both answers — minimumToOpenDmWith(recipient) and minimumTipFor(userId, recipient) — so the three entries can't drift apart. The fee is stored in whatever currency the recipient set it in, so it converts through USD into the currency the sender is entering in; when either leg has no rate it falls back to the preset rather than state a floor in a currency the entry isn't using.

Two consequences fall out of the same rule:

  • The in-chat entry says "Swipe to Tip" only for the payment that opens the DM. After that it reads "Swipe to Send" and drops the floor hint, like a contact DM. The label and the floor now read one flow, so they cannot disagree.
  • A preset chip below the recipient's floor would be rejected on send, so it isn't offered. confirmTip re-checks the floor because a chip never passes through the amount entry.

Also fixes the below-minimum prompt to match node 9553:20236 — "$5.00 Minimum Tip / Please enter a higher amount", was "$5.00 Minimum / Increase the amount to send" — and moves the custom entry's copy of it from a destructive alert to the info style the other two already used, following #1361. The standing hint reads "$5.00 minimum".

…ns the chat

Both the in-chat amount entry and the custom tip entry floored at the regional
preset minimum, which is not the amount the recipient set. #1360 gave users
their own minimum, `UserProfile.minDmChatInitFee` — the fee another user pays to
open a DM with them — and neither entry read it.

The fee buys the conversation, so only the payment that opens it pays:

- `TipPaymentDelegate.minimumToOpenDmWith` is that floor, converted through USD
  into the currency the sender is entering in, falling back to the regional
  preset when the recipient charges nothing or a rate is missing.
- `minimumTipFor(userId, ...)` charges it while no DM with that user exists and
  the system minimum once one does. The tip card follows it: presets below the
  floor are dropped from the modal, and `confirmTip` checks it, since a preset
  chip never passes through the amount entry.
- The in-chat entry applies it to the send that opens the chat and drops the
  floor entirely afterwards. A contact DM never had one.

The standing hint reads "$5 minimum" rather than "Minimum tip $5", matching the
prompt that blocks a send below it.
The prompt read "$5.00 Minimum / Increase the amount to send"; node 9553:20236
has "$5.00 Minimum Tip / Please enter a higher amount". Both strings are shared
by the three places that raise it — the chat send, the tip card, and the custom
amount entry.

The custom entry raised it as a destructive alert while the other two used the
info style, so it also moves to info: nothing has failed, the amount is just
under the floor.
The in-chat entry said "Swipe to Tip" for the whole life of a tip DM. Only the
first payment is a tip: it pays the recipient's fee to open the conversation.
Every one after it is an ordinary send with no minimum, so it now reads "Swipe
to Send" and drops the floor hint, the same as a contact DM.

The label and the floor were already asking the same question separately; both
now read one flow, so they cannot disagree.
@bmc08gt bmc08gt self-assigned this Aug 28, 2026
@github-actions github-actions Bot added type: feature New functionality area: payments Payments, transfers, intents, billing and removed type: feature New functionality labels Aug 28, 2026
@bmc08gt
bmc08gt merged commit 3b14eed into code/cash Aug 28, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: payments Payments, transfers, intents, billing

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant