How a QR payment with DANA works
The flow has the same four steps in almost every setting:1. The merchant shows a code. This can be a printed code fixed to the counter, a code on a small stand, or a code generated for one specific sale with the amount already filled in. 2. The customer scans it. The customer opens the DANA app or a participating bank app, points the camera at the code, and the app reads the payment details. 3. The customer checks and confirms. The app shows the payee name and the amount. The customer confirms the payment, often with a PIN, fingerprint, or face check. 4. Both sides see a confirmation. The customer sees a success screen, and the merchant checks their own confirmation before handing over the goods.
Two details make the difference between a smooth till and a disputed sale. First, a code with the amount already filled in removes the most common error, which is the customer typing the wrong amount. Second, the merchant should confirm the payment in their own app or on their own receipt record, not only by glancing at the customer phone screen. A customer screen can be faked or can show an older payment, so your own confirmation is the one that counts.
If your setup supports both a printed merchant code and a customer-presented code, learn which one your provider expects for each sale type. A printed merchant code suits counter sales, while a customer-presented code suits situations where the merchant scans the customer phone. Mixing them up is a common cause of a failed first attempt.
Setting up QR payments with DANA
Follow these steps in order, and test with a small real payment before you rely on the code for a full day of trade:1. Check what your provider supports. Your bank, wallet provider, or payment provider can tell you whether it issues DANA merchant codes, what the customer sees, and how merchant confirmations arrive. 2. Complete verification. Most providers ask for business or identity details before issuing a merchant code. Gather the documents first so the application is not left half finished. 3. Get your merchant code. Ask for a code that shows your business name as the payee. A code that shows a bare account number or an unfamiliar name will make customers hesitate. 4. Decide between a fixed code and per-sale codes. A fixed printed code suits a counter where customers enter the amount. A per-sale code with the amount filled in suits invoices, deliveries, and higher-value sales where a typo would be costly. 5. Print and place it. Print at a size that scans comfortably from a normal standing distance, keep the code flat and glare-free, and place it where the customer naturally stands to pay. 6. Run a live test. Pay yourself a small amount with a different phone, check that the merchant confirmation arrives, and confirm the money lands in the expected account. 7. Train anyone who takes payments. Everyone at the till should know the confirmation routine, the fallback when a confirmation is slow, and how to handle a customer who says the payment went through but your side shows nothing. 8. Reconcile daily. Compare the day QR receipts against your provider statement. A short daily check catches a missing or duplicated payment while the details are still fresh.
On fees, do not guess. Ask your provider for the current fee schedule, including any per-transaction charge, monthly charge, payout timing, and refund handling, and read it before you set prices. Fee terms change, and a fee quoted by another merchant may not match your own agreement.
Where DANA fits best
DANA fits best where your customers already use it. Counter sales are the natural starting point: the customer is standing in front of you, the amount is clear, and the scan takes seconds. It also suits invoices and deliveries, where a code on the invoice lets the customer pay from their phone without a return visit, and a code on a delivery note covers payment on handover.It suits less well where the amount is not known until late, where several people share one till, or where the customer needs a formal receipt from a separate system. In those cases, keep DANA as one option alongside your existing method, and decide in advance which method is the default for each sale type. A mixed setup works when staff know the rule; it fails when every sale becomes a negotiation about how to pay.
If some customers do not use DANA, keep a second option available and signpost both. A customer who cannot pay is a lost sale, and a short sign that names each accepted method prevents an awkward conversation at the till.