Written by DROPS.ST.
Name a payment method by what the customer will use, then explain what happens after they choose it. A payment selection, an order submission and a completed payment are different events. DROPS brings payment status into the order flow, giving customers clearer next steps and staff a shared record for answering payment questions.
Replace internal names with customer actions
Customers should not have to know your payment provider’s name or an internal accounting label to decide how to pay. “Bitcoin (BTC)” tells them the asset. “Manual transfer” needs the actual approved arrangement and an explanation of the next step.
A shop-account balance also deserves a clear label. Customers may otherwise confuse credit held within the shop with a cryptocurrency wallet they control. State what balance is being used and what happens when it does not cover the total, based on the configured behaviour.
Use the alternative payment options guide to review the arrangements you actually support. The checkout should show those choices accurately, without suggesting unavailable card payments or unsupported assets.
Pair each label with one useful sentence
The following wording illustrates the structure. It is not a promise that every method is available in every shop.
| Method | Customer-facing label | Explanation to adapt to the real flow |
|---|---|---|
| BTC checkout | “Bitcoin (BTC)” | “Continue to see the payment amount and instructions for this order.” |
| XMR checkout | “Monero (XMR)” | “Continue to the XMR payment instructions, then return to your order status.” |
| Approved manual arrangement | The actual transfer method’s name | “Place the order, then follow its payment instructions. The order remains unpaid until payment is accepted.” |
| Shop balance | “Use shop account balance” | “Pay with the available balance shown in your account.” |
Keep the label short enough to scan on a phone. Put the explanation beside the choice, not exclusively in a policy page customers may never open.
Say what the button does
A button labelled “Pay now” creates the expectation that the action itself makes a payment. If it only creates an order and opens instructions, wording such as “Continue to payment” or “Place order and view instructions” can be more accurate.
Use the exact button options the product supports. When the text is fixed, make the surrounding explanation do its job and ask to inspect the complete flow in a demo. The success screen must also match the event: an accepted order request is not automatically a paid order.
For example, a fictional customer selects a manual transfer option and sees “Order received.” They should also see that payment is still required and where the current instructions live. That prevents a mistaken assumption that the shop has already charged them.
Keep payment and fulfilment expectations separate
A payment update tells the customer about payment. It does not necessarily mean the order is packed, ready for pickup or dispatched. Give each stage its own clear meaning.
DROPS order and payment status help your staff answer the immediate question without searching several channels. The commercial benefit is practical: fewer uncertain customers abandoning a payment step and fewer avoidable “Did it go through?” messages for the team.
In a demo, choose each intended method and inspect the first screen after selection. Check the asset name, amount, order reference and next action. For account balances, inspect the explanation with sufficient and insufficient balance. Do not assume split-payment behaviour without seeing it.
Keep explanations consistent beyond checkout
Support replies and order messages should use the same method names. A customer who selected “Monero (XMR)” should not receive an unexplained request to “settle the invoice through gateway two.”
The Bitcoin and Monero checkout guide helps assess whether both choices fit your shop. Explore DROPS payments within a complete shopping experience and make every payment option tell customers what to do next.