Written by DROPS.ST.
Software signup, payment-provider approval and buyer eligibility are separate decisions. Identify who requests each piece of information, why they need it and what decision it supports before treating an account as permission to trade.
DROPS provides the working shop context: products, package choices and customer-linked orders stay organised, with the website and connected Telegram shop sharing catalogue and order data. That gives your team concrete records for operating the shop while the appropriate people own the verification decisions.
Those records do not establish native bank underwriting, business verification or legal buyer approval. Check the actual signup process and separate requirements rather than relying on a broad “no-KYC” claim.
Define the terms and the decision
KYC means “know your customer.” KYB means “know your business.” They describe verification work, but the acronym alone does not tell you who requires it or whether two services ask for the same evidence.
A software provider may request account and support details. A financial provider may assess the business and its owners. A seller may need information about a particular buyer or receiving location.
Ask what happens after each review. Creating an account, approving payment services and approving a particular transaction are different outcomes.
Map the layers
| Layer | Decision and responsible party | Question to ask |
|---|---|---|
| Software account | Provider grants the agreed software access | Which fields and checks apply to this service? |
| Bank or payment service | Provider assesses its customer and proposed activity | Which products, markets and fund flows are approved? |
| Shop customer | Operator checks the intended customer/order relationship | What must be established before this order proceeds? |
| Wholesale buyer | Responsible business reviews purchasing and receiving authority | Which entity, contact and destination are eligible? |
| Required business records | Operator and appropriate advisers determine what must be retained | What evidence is required, where and for how long? |
Use this as an original responsibility worksheet, not a universal list of legal requirements. Record the actual requester, purpose, evidence source, decision owner and unresolved condition for your business.
Keep a dated checklist of the provider’s actual requests, required evidence, response owner and unresolved questions. Describe the products, markets, channels and fund flows truthfully, including accessories or a proposed new category. Retain the written scope decision; a salesperson’s introduction, provider logo or working checkout is not that approval.
Give each data request a purpose
Ask why the information is needed, whether it is required at this stage, who receives it, how it is protected and what retention applies. Distinguish required records from optional contact or marketing choices.
OPC's Canadian PIPEDA guidance limits personal-information collection to the identified legitimate need. It supports questioning unnecessary collection, not deleting required verification or recordkeeping. OPC: limiting collection.
For processing locations and access, use the software data-location questions. A statement about where records are stored does not answer who decides eligibility.
Check the actual payment role
Record who receives the buyer's payment, who controls transfers and whether another party converts or remits funds. Do not infer the role from the word “platform” or “wallet.”
FINTRAC distinguishes payment intermediaries and virtual-currency services from the specified own-goods payee exception. Assess the actual activities and fund flows; that distinction is not a blanket exemption from identity, tax or other obligations. FINTRAC: money services businesses.
For Canadian cannabis operations, use the requirements applicable to the actual province or territory. Health Canada identifies their responsibility for cannabis sales and store-operation rules. Health Canada: provincial and territorial responsibilities.
Cannabis, nicotine products and other regulated goods need their own product and provider scope. One approved activity does not automatically cover another.
Use the buyer row for a pilot customer, partner account or returning business. A lead, old login or historical order does not establish current purchasing authority. Preserve relevant history while checking today’s entity, contact, destination and approved terms through the actual process.
Hypothetical example: the shop exists, approval is pending
A fictional business prepares a menu while its payment approval and a buyer’s receiving details remain unresolved. The owner records three outcomes: software access available, payment decision pending and buyer review pending. Each question goes to its decision owner through the approved process. A working menu proves neither outstanding approval. This is not a description of DROPS signup fields.
Choose a clearer shop foundation with DROPS
Choose DROPS when you want product choices and customer-linked order records together while your team keeps verification responsibilities explicit. The shared web and connected Telegram order system gives the operator a consistent shop context without replacing required checks.
Explore DROPS and open the demo shops. Inspect the shop and order experience, then compare the actual software-data requests and separate provider/buyer requirements against this map.