QRIS, GoPay & OVO: Monetizing Song Requests in Your Venue
Ardi Setiadharma
Founder, eJukebox
Indonesia skipped credit cards and went straight to QR payments. That is exactly why paid song requests work here better than almost anywhere else: the guest is already holding a phone that can pay in three taps. Here is how to design the payment side of a song-request system that actually generates revenue.
Why Local Payments Are the Whole Game
A paid song request is an impulse purchase worth Rp 5,000–25,000. Impulse purchases die the moment friction appears. Ask an Indonesian guest to enter a credit card number for Rp 10,000 and the conversion rate rounds to zero. Show them a QRIS code they can pay with GoPay, OVO, Dana, ShopeePay, or any mobile banking app — the same gesture they used to pay for lunch — and paying for a song becomes as natural as ordering es teh.
The numbers from venues running eJukebox's local payment integration bear this out: mobile-payment token purchases convert at 3–4x the rate of any card-based flow, and the median time from scan to completed payment is under 25 seconds.
Understanding the Fees (MDR)
Every payment method carries a merchant discount rate (MDR), and at song-request price points the difference matters:
- QRIS — Bank Indonesia regulates the MDR at 0.7% for regular merchants; micro-merchants (UMI category) enjoy reduced or zero MDR on small transactions under BI's tiered scheme. On a Rp 10,000 token that is at most Rp 70.
- E-wallet direct integrations (GoPay, OVO, Dana) — typically 1.5–2% via aggregators, but with deeper UX (in-app deeplinks, no camera needed).
- Virtual accounts / bank transfer — flat fees around Rp 2,000–4,000, which destroys margins on small purchases; reserve these for large token bundles only.
Practical rule: route single-token and small purchases through QRIS, and offer e-wallet deeplinks as a convenience option. For bundles above Rp 100,000 (parties, events), all methods are margin-fine.
Token Pricing That Works in Indonesia
Selling rupiah-denominated songs directly ("this song costs Rp 8,000") feels transactional and invites price comparison. Tokens abstract that away and enable bundle psychology:
- 1 token = Rp 5,000 — standard queue request
- 5 tokens = Rp 22,500 (10% bonus) — the most popular bundle in practice
- 12 tokens = Rp 50,000 (17% bonus) — group/table bundle
- Priority play: 3 tokens; next-song: 5 tokens; dedication with name on screen: 10 tokens
Two design details drive most of the revenue. First, price the entry token at psychological pocket-change level — Rp 5,000 in 2026 is a parking fee. Second, make the middle bundle the obvious choice: guests who buy 5 tokens use them, and unused tokens on a wallet are the single strongest driver of return visits.
Designing the Flow
The complete loop should take under a minute:
- Guest scans the table QR code → lands on your venue's request page (no app install)
- Searches the catalog, picks a song, sees the token price
- Taps pay → dynamic QRIS or e-wallet deeplink → confirms in their payment app
- Song enters the queue with position shown; guest gets a confirmation with queue ETA
Show the queue publicly (on a screen or in the web app). Visibility is the flywheel: guests who see other people's paid requests moving up the queue understand the system instantly, and priority-play upsells sell themselves during busy hours.
A Realistic Revenue Scenario
Take a mid-sized bar with 80 covers on a Friday night. If 30% of guests buy tokens at an average of Rp 20,000 (mostly the 5-token bundle), that is 24 buyers × Rp 20,000 = Rp 480,000 per night in pure music revenue. Across Friday–Saturday plus weaker weekdays, venues commonly report Rp 4–8 million per month — enough to cover the entire music system and licensing costs with margin left over. Our bar solution page walks through how high-energy venues push this further with song battles and happy-hour token promos.
Promotions That Move the Needle
Once the payment rail works, promotions are almost free to run because they are configuration, not printing:
- Happy-hour token multipliers — "tokens worth double, 5–7 PM" pulls request activity (and guests) into your weakest hours
- First-request-free for new wallets — the free first song teaches the flow; paid conversion follows naturally once guests have seen their song play
- Table bundles with minimum spend — "free 5-token pack with every large sharing platter" ties music revenue to food revenue instead of competing with it
- Event nights — audience voting in song battles at 1 token per vote reliably outsells standard requests on event nights
Reconciliation and Operations
- Settlement timing — QRIS and e-wallet settlements typically land T+1; treat music revenue as a separate ledger line so it does not blur into F&B
- Refund policy — decide upfront what happens when closing time cuts the queue; auto-crediting unplayed tokens back to the guest's wallet is cheaper than refunds and drives return visits
- Offline handling — payments need internet even when playback does not; a good system queues completed-but-unsynced transactions and reconciles when connectivity returns
- Dispute hygiene — keep the request log (song, timestamp, amount, payment reference) exportable; the rare "I paid but my song never played" conversation ends in seconds when the log shows the song played at 22:14
- Tax note — token sales are venue revenue; discuss with your accountant how they fold into your PB1/service charge treatment
Song requests are one of the few venue revenue lines with near-zero marginal cost — the music is already playing. Pair the QR request flow with payment methods Indonesians actually use, price tokens like pocket change, and check our pricing page to see how quickly the system pays for itself.
Share this article