Written by DROPS.ST.
Define shop-controlled crypto checkout by the specific decisions and actions your business can perform. Choosing the payment methods or viewing an order's status is different from holding signing authority, moving funds or controlling a service provider's account restrictions.
DROPS gives the operational review a clear foundation: configured BTC and XMR payment steps connect to shop order references and status, while customer-linked items identify the purchase. The website and connected Telegram shop share the catalogue and order system.
That shop context does not establish custody or key control; verify those arrangements from the actual architecture, permissions and governing service terms before making a claim about them.
Separate the kinds of control
Start with what the shop operator means by “control.” It may concern which methods appear, who answers a support question, who authorises fulfilment or who can change a financial setting. Those need separate evidence.
Protocol authority is another question. Monero's documentation distinguishes a private view key used to inspect incoming payments from a private spend key used to spend funds and sign transactions. That illustrates why seeing payment information is not the same as possessing spending authority. Monero: view key, Monero: spend key.
This distinction does not describe where any DROPS deployment stores keys or who controls them. Do not request or copy secret key material to complete a marketing worksheet.
Build a control-and-evidence register
Use this original aid before describing the setup publicly. Record the exact actor, demonstrated capability and evidence location without placing credentials in the sheet.
| Control question | Evidence required | Public wording boundary |
|---|---|---|
| Who selects available methods? | Actual configured settings and authorised role | Describe the demonstrated method choices |
| Who sees order/payment context? | Relevant view and its permission scope | Describe access to the shown records |
| Who changes sensitive settings? | Effective role and approved change process | Do not equate ordinary staff access with financial authority |
| Who can authorise transfers? | Documented signing/access arrangement and actual process | Keep fund-control claims pending until established |
| Who holds or processes funds? | Architecture and governing service terms | Do not infer custody from a checkout screen |
| Who handles disputes or closed requests? | Approved reviewer, evidence and decision route | Describe the supported issue process |
An unanswered row is a substantive question. Do not replace it with “shop-controlled” and assume the phrase answers the underlying responsibility.
Compare role access with the intended job
Separate staff who locate an order, staff who update catalogue information and people authorised to make financial decisions. Review actual permissions rather than assigning meaning to a role name.
The current product context includes account and credit-related access scope. That makes the permission review relevant; it does not establish a narrow product-only role, a transfer approval trail or a funds-release workflow.
Use the staff permissions checklist for the supported role review. Keep any provider or wallet authority outside that checklist unless it has been demonstrated separately.
Hypothetical example: a payment view without transfer authority
A fictional support role can locate an order and its payment state. The operator assumes this means the role also controls the payment arrangement and can resolve an excess receipt.
The reviewer checks the intended task and actual permissions. The role can answer the order-status question, but the transfer authority and excess-receipt decision are not established. Those questions remain assigned to the appropriate owner.
The public description says that staff can inspect the relevant order and status. It does not claim that the role controls funds or that the platform automatically issues a refund.
This is an authority-mapping example, not a statement about a live account or custody configuration.
Match the marketing claim to its evidence
Explain concrete buyer-visible behaviour: the available asset, current instructions, order reference and status. Avoid using a protocol or custody label as a substitute for an understandable customer journey.
A claim about private-key possession needs different evidence from a claim about order visibility. A claim about provider restrictions needs the actual applicable terms, not an assumption based on a product logo or a successful demonstration.
The gateway and wallet comparison evaluates acceptance, merchant receipt, verification and custody questions across proposed arrangements. This register records what your chosen setup actually permits each actor to do.
Revisit the register when roles, providers or the architecture change. A previous description should not silently become a claim about a different arrangement.
Choose clear shop operations with DROPS
Choose DROPS when you want crypto checkout connected to products, customers and order status. Its common web and Telegram shop context gives the control review concrete operational records to inspect.
Explore the DROPS demos using the register. Check the available order and payment views, then identify the architecture and permission evidence still needed for fund-control claims. Choose the setup by demonstrated responsibilities rather than an undefined custody slogan.