Konbini payment integration that turns cash-preferring shoppers into paid orders

What is konbini payment integration?

Konbini payment integration is the technical work of offering “pay at a convenience store” at your online checkout and making your order system react correctly when that cash payment arrives, or does not. It connects three parties: your website or app, a payment processor licensed to issue konbini payment codes, and the convenience store chains that collect the cash.

From the shopper’s side it looks simple. They choose konbini at checkout, see a payment code and a confirmation number, walk to a FamilyMart, Lawson or similar store, and pay at the counter or the in-store terminal. From your side, the order sits in a waiting state, sometimes for days, until the processor tells your server the money has been collected. Only then should you ship, confirm a booking or open access to a course.

That waiting state is what separates konbini from card payments, and it is where most of the engineering lives. A card is approved or declined within seconds. A konbini payment is a promise that may or may not be kept before its deadline. Good konbini payment integration therefore covers the whole lifecycle: issuing the voucher, reminding the customer, holding stock or seats, receiving the paid notification, cancelling cleanly when the voucher expires, and refunding cash when a customer returns something.

The word “integration” matters too. Most processors hand you a payment method; they do not decide how long your seats are held, what email a customer gets on day two, or how your warehouse knows an order is now safe to pack. Those decisions are yours, and we build them.

Why do Japanese customers still choose to pay at a convenience store?

Because it lets people buy online without a credit card and without typing card details into a site they have never used before. For shops selling to younger customers, first-time buyers or households that budget in cash, a checkout without konbini quietly turns some of them away.

Several kinds of shopper reach for it. Students and teenagers often have no card of their own. Some adults prefer not to put card numbers on smaller or unfamiliar sites. Others like paying for a child’s course or a concert ticket in cash so the spending is visible. And some simply pass a convenience store on the way home every day, so paying there costs them nothing extra in time.

The categories where konbini tends to matter most are ones where trust is still forming or the buyer is not the cardholder: fashion and hobby ecommerce, event and concert tickets, online courses and cram-school fees, game and digital content (subject to your processor’s rules), mail-order food, and first orders from new direct-to-consumer brands.

We do not quote market-share figures on this page, because they vary by survey and by category. The practical test is your own data: if your abandoned carts cluster at the payment step, or customer emails ask “can I pay at a konbini?”, konbini payment integration is worth scoping.

How does a konbini payment work, step by step?

The shopper chooses konbini, your server asks the processor for a payment, the processor returns store-specific payment codes, the shopper pays cash in store, and the processor notifies your server. Your system reacts to that notification, not to the shopper saying they paid.

• Checkout: the customer selects convenience store payment and enters a name and email; many setups also take a phone number as the confirmation number
• Voucher issued: the processor returns a payment code and confirmation number for each supported chain, plus a deadline, which your site shows and emails
• Waiting: your order is marked awaiting payment; stock, seats or a delivery slot are held according to the rules you set
• Payment in store: the customer gives the code at the counter or terminal and pays in cash, keeping the receipt
• Notification: the processor sends a webhook to your server saying the payment succeeded; your system marks the order paid and starts fulfilment
• No payment: if the deadline passes, the processor sends a failure event and your system cancels the order, releases what was held and offers another way to pay

One global processor’s documentation, for example, lists FamilyMart, Lawson, Ministop and Seicomart as supported chains, confirms payment instantly once cash is paid, and makes funds available for payout after four business days. Japan-focused aggregators list additional chains, including 7-Eleven and Daily Yamazaki. The chain list is one of the first things we compare when helping you choose a processor.

Choosing a processor for konbini payment integration

Pick the processor first, then design the integration around its rules; switching later means rebuilding webhooks, refunds and reports. The choice usually comes down to three routes, and the right one depends on your platform, your entity and which chains your customers use.

We do not resell any processor and take no referral fees, so we can compare honestly. We ask four questions: Which chains does it cover? Does it accept your business type and entity? Does your platform (Shopify, WordPress, a custom stack, a native app) have a maintained integration? And how do refunds of cash payments work? You then sign directly with the processor you choose.

Your contract, fees and payout schedule are negotiated by you; we read the technical documentation and build against it.

Konbini payment limits, deadlines and text rules to design around

Every processor sets a minimum and maximum amount per konbini payment, a voucher deadline and rules for the text printed at the store. Your checkout has to respect them, or orders fail at the last step. Here is how one widely used global processor documents them.

Its konbini payments must be in Japanese yen, with a minimum of 120 yen and a maximum of 300,000 yen per payment. A basket above the ceiling needs another method, so your checkout should hide konbini for large orders instead of letting the customer reach an error.

The deadline defaults to three days and can be set from one to sixty days, expiring just before midnight Japan time (23:59:59 JST) on the final day. A timestamp can be used instead, but it must be at least thirty minutes away. Your choice is a business decision: a longer window suits course fees paid on payday; a shorter one suits limited-stock drops, where holding items for a week would be costly.

The text rules catch people out. The product description shown at the store is limited to 22 characters, and characters outside the Shift JIS set cause an error. Customer names are truncated to 20 characters on store screens and receipts. So a brand name with emoji, or a long English product title, needs a short Japanese-friendly descriptor set by the integration.

Other processors have their own figures; part of our konbini payment integration work is putting them into a single configuration file so a change of processor, or a new limit, is one edit rather than a hunt through the code.

What do processors check before approving konbini payments?

They check your website as much as your paperwork. Konbini approval is often decided by the convenience store chains and the processor’s financial partner, and a site with missing business details or a thin disclosure page can be rejected even when the code works.

One global processor publishes its onboarding checklist for konbini, and it is a useful model for any konbini payment integration. Reasons it gives for rejection include:

• The payment and checkout flow is not clearly explained on the site
• Business name, address, email and phone do not match the application or are hard to find
• Customer support hours are missing or incomplete
• The Specified Commercial Transactions Act disclosure is missing, incomplete or does not match the application
• Product descriptions, prices, shipping or extra fees are incomplete or unclear
• Cancellation terms and any recurring charges are not explained
• Pages are private, broken, behind a login, or return 404 errors, or the postal code is missing or wrong

The same processor adds that sole proprietors must show a photo of their storefront and excludes sole proprietors trading for less than three years, along with categories such as gambling, loans, dating sites, fortune-telling and vaping products. Aggregators and domestic gateways publish their own lists. Before you apply, we walk through the site with the relevant checklist so the review goes through the first time wherever possible.

The tokushoho page: what a konbini checkout needs you to disclose

Online sellers in Japan must display specific trading details under the Specified Commercial Transactions Act, usually on a page titled 特定商取引法に基づく表記 (tokushoho page), and processors check that page before enabling konbini. We build it into the site; you and your lawyer confirm the wording.

The Consumer Affairs Agency’s guide to mail-order rules lists what sellers must show, including:

• Sales price and shipping costs, plus any other costs the customer pays
• When and how payment is made, which is where konbini deadlines belong
• When the product is delivered
• Terms for cancellation, withdrawal and returns
• The seller’s name, address and phone number, and for companies the name of the representative or responsible person
• For overseas businesses, the office location and phone number in Japan

For konbini payment integration specifically, the payment section should state the payment deadline, that orders are cancelled if unpaid, whether a handling fee applies, and when goods ship after payment. Keep it consistent with your checkout, emails and processor application: mismatches are a common reason for a rejected konbini application. We are developers, not legal advisers, so we lay out the page and wire it to your footer and checkout; the content is yours to confirm.

Konbini payment integration on Shopify vs a custom checkout

On Shopify you add konbini through a payment provider that supports it; on a custom site or app we integrate the processor’s API directly and build the waiting state ourselves. Shopify is faster to launch; custom gives you control over holds, reminders and non-retail flows such as bookings.

Shopify’s Help Center lists the methods available through Shopify Payments in Japan as cards (American Express, JCB, Mastercard and Visa, with JCB limited to JPY transactions) and accelerated checkouts such as Apple Pay, Google Pay and Shop Pay. Konbini is not on that list, so Shopify merchants add it through a third-party payment provider that supports it, usually alongside Shopify Payments for cards. Our job there is choosing and configuring the provider, adjusting order notifications so a konbini order is clearly “awaiting payment”, and making sure fulfilment apps do not pick unpaid orders.

On a custom build, whether a headless storefront, a WordPress site, a booking tool or a Flutter app, konbini payment integration is closer to the metal. Your server creates the payment, stores the returned voucher details, shows them in your own design, and runs a webhook endpoint that listens for paid, expired and refunded events. That extra work pays off when konbini must interact with things Shopify does not know about, such as seat maps, lesson calendars or member points.

Decision rule: if you sell physical goods from a catalogue and are on Shopify already, stay there and add a provider. If you sell time, seats, access or subscriptions, a custom integration is usually cleaner. For WordPress shops, see our WordPress developer for Japan page.

Adding PayPay, JCB cards and bank transfer next to konbini

Most Japanese checkouts offer konbini as one option among four or five, not on its own. The usual set is cards including JCB, a QR wallet such as PayPay, konbini, and bank transfer, with Apple Pay or Google Pay as accelerators. We build them as one consistent checkout with one order model.

Cards settle immediately, so they follow the normal paid flow. JCB is a Japanese card brand that many domestic shoppers carry, and it is supported through most processors that operate in Japan; check that yours covers it. QR wallets such as PayPay are approved in the customer’s app and usually return a result within the checkout session, which makes them behave more like cards than konbini.

Bank transfer behaves like konbini: the customer pays later, and your system waits. The pain point is matching. When customers send money with the wrong reference, staff end up reading statements line by line. Where your processor offers virtual account numbers per order, we use them so each transfer is matched automatically; otherwise we generate clear reference codes and build a matching screen.

One more rule: after LINE Pay ended its service in Japan in April 2025, any old checkout still showing it needs cleaning up. We check your checkout for dead methods as part of every konbini payment integration.

What happens when a konbini voucher is never paid?

The order must cancel itself cleanly: stock or seats go back on sale, the customer is told politely, and they get an easy way to pay again. Leaving unpaid orders open is the most common mistake in konbini payment integration, and it quietly distorts stock counts and sales reports.

The processor tells you when a voucher has lapsed. One global processor, for instance, sends a payment-failed event when it is clear the payment did not happen, typically about an hour after the deadline, because a customer who printed a slip in time may still be completing payment at the register. Your system should wait for that event rather than cancel on the dot of midnight.

What happens next is your policy, which we turn into code. Common rules we build:

• Reminder the day before the deadline, by email or a LINE message if the customer is linked, with the payment code repeated
• Stock held until the processor’s failure event, then released automatically
• For limited items, a shorter voucher window so stock is not locked for days
• A “pay another way” link that reopens checkout with the same basket and cancels the old voucher
• An internal report of expired vouchers by product, so you can see whether a price or deadline is putting people off

Cancelling an open voucher before its deadline is possible too, for example when a customer switches to card. The processor’s original payment instructions then stop working, so the integration must tell the customer immediately to avoid someone paying a dead code.

How do refunds work for konbini payments?

Because the customer paid cash, the money cannot go back to a card. The refund goes to a bank account the customer provides, which adds steps, delays and a few ways to fail. Your konbini payment integration needs screens and emails that make this obvious.

In one global processor’s documented flow, you create the refund in the dashboard or API, the processor emails the customer asking for bank details, and once they are submitted the refund is sent automatically. If the account name does not match what the bank holds, or the number has a typo, the funds come back and the customer is asked again. If the customer never provides details within 45 days, the refund fails and you must return the money another way. Each refund, including partial refunds, may also carry a fee.

We design around those facts. The customer’s refund email is sent from your brand, not only from the processor, and explains in plain Japanese (your wording) that they will receive a request for bank details. Staff get a list of refunds still waiting for the customer, with ages, so nothing silently expires. And your returns policy on the tokushoho page describes the same process.

For businesses with frequent partial refunds, such as a cancelled item in a mixed basket, we sometimes suggest store credit or points as an alternative your policy can offer. Whether that fits your obligations is for your own advisers to confirm.

Can konbini be used for subscriptions, invoices and B2B orders?

Yes, but not as an automatic charge. A konbini payment always needs the customer to go to a store, so recurring billing becomes a recurring invoice with a payment code each cycle. The integration must plan for missed cycles.

One global processor’s billing documentation, for example, supports konbini on subscriptions and invoices only with the “send invoice” collection method, and states that automatically charged invoices are not supported because of the in-person nature of the payment. The same principle applies elsewhere: each period, the customer receives a new code.

For a monthly box, a course or a membership, konbini payment integration then needs a grace policy. Does the next box ship before the invoice is paid? Does a member lose access on day one of non-payment or after a week? We build those rules, plus reminders, and encourage switching to card or PayPay for customers who are happy to do so.

B2B buyers in Japan more often pay by bank transfer against an invoice, sometimes at month end. If your buyers are companies, that flow usually matters more than konbini, and we will scope it first.

Konbini payment integration in mobile apps and LINE MINI Apps

It works the same way inside an app: the app requests a payment from your server, shows the payment code on screen, and updates the order when your server receives the paid event. The difference is where the customer sees their code and reminders.

In a Flutter or React Native app, we store the voucher details against the order so the code is always one tap away, and send a push notification before the deadline. Selling digital items inside an app may fall under the App Store’s and Google Play’s in-app purchase rules instead, so we check that before designing any konbini route for in-app content.

Inside LINE, a LINE MINI App can show the code, and a LINE chatbot linked to the customer can send the reminder and the “payment received” message, which many customers notice faster than email. LY Corporation requires separate approval for in-app purchases in MINI Apps, so physical goods, bookings and services are the straightforward cases.

For costs of the app itself, see our app development cost guide for Japan.

Testing a konbini payment integration before real customers use it

Test every branch, not only the happy path: paid immediately, paid later, expired, cancelled and refunded. Most processors offer a test mode that simulates each outcome, so there is no reason to find a bug with a real customer’s cash.

The global processor we have referred to lets developers trigger outcomes with special test email addresses or confirmation numbers: a payment that succeeds after three minutes, one that succeeds immediately, one that expires immediately, one that expires after three minutes, and one that never succeeds and expires on its real deadline. It also provides test bank accounts for refunds that succeed or fail.

Our test plan for konbini payment integration covers each of those, plus the things around them: stock counts before and after, emails and LINE messages sent at each step, staff screens, reports, and what a customer sees if they reload the voucher page after it expired. We also send duplicate and out-of-order webhooks on purpose, because networks do that, and the order system must not ship twice or cancel a paid order.

You receive the test sheet with results, and your staff run through the customer journey themselves before launch.

How much does konbini payment integration cost, and how long does it take?

With us, a new store launched with konbini and the other Japanese methods starts at US$750 and takes four to eight weeks. Konbini inside a booking, ticketing or membership system starts at US$900 and takes six to twelve weeks. Adding konbini to an existing checkout is quoted after a code review.

Other developers’ quotes for konbini payment integration vary widely. The spread usually comes from how much of the lifecycle is included: switching on a method is quick; designing holds, reminders, cancellations, refunds and reports takes real time. Ask each quote to list those items separately.

• Platform: Shopify with a provider app is faster than a custom API integration
• Number of payment methods and whether they share one order model
• What the waiting state touches: stock, seats, lesson slots, access rights
• Reminder channels: email only, or LINE and app push too
• Refund volume and whether staff need their own refund screens
• Reports and accounting exports your team needs
• State of the existing code, if we are adding to it

Processor fees are separate and paid by you to the processor. After launch, two months of maintenance are free; payment care after that starts at US$120/mo per month.

Working with a team in India on your Japanese checkout

India is three and a half hours behind Japan, so our working day overlaps your afternoon from about 12:30 JST. Payment projects need careful sign-offs, and the overlap is enough for a short daily check-in plus demos.

Accounts stay with you. You sign the merchant contract, open the cloud account and own the code repository; we get the narrowest access that works, usually developer keys for test mode first. Live keys go into your cloud secret store, and we never have access to payouts or your bank account. When the project ends you revoke our access, and nothing needs transferring.

The project runs in English. Japanese text customers will see, such as the voucher screen, reminder emails and refund instructions, is written or approved by you, and we build it in exactly. Processor dashboards in Japanese are fine: we work from the English documentation where it exists and ask when a setting is unclear.

Quotes are in USD and can be paid in USD or JPY by Wise or bank wire, with milestones written into the quote and nothing billed before your written approval. Invoices come from India; your accountant can advise how to record them.

The first two weeks usually look like this: a scoping call, a written order-state diagram covering paid, waiting, expired and refunded, your processor test account shared with us, and by the end of the second week a working konbini voucher in test mode on your staging site.

Example scenario: a hypothetical online cram school in Saitama adds konbini

This is an invented scenario to show how konbini payment integration might be scoped, not a client story. Imagine a small cram school in Saitama that sells online courses and exam-prep packs to secondary-school students. Parents pay, many prefer cash, and the school currently emails bank details and checks the statement by hand.

The first release would add a checkout with card, PayPay, konbini and bank transfer to the school’s existing site. Konbini vouchers would last seven days, to fit families who pay at the end of the week, and the course would open automatically when the paid event arrives. A reminder would go out the day before the deadline. Expired vouchers would release the seat in a capped live class and email a “pay another way” link. Bank transfers would use per-order reference codes with a matching screen for staff.

Because course access and class capacity are involved, this would be quoted as a custom system from US$900, over roughly six to eight weeks. A later phase might add monthly tuition billed as a konbini invoice each month, with a one-week grace period set by the school.