The question turns up several times a week, in more or less these words: which payment gateway can I use without a company, and settles to a personal account? The replies arrive fast and they are all provider names. Twenty of them, no two the same, and not one of them wrong exactly.
They are just answering a question the person did not ask. I watched one thread do this to somebody who had been perfectly clear: he wanted a personal account and batch disbursement. Fourteen replies, every one of them a brand name, and the two most confident ones told him a provider “works for individuals” without noticing that this was true of only half his requirement.
The split below is the whole article. Everything after it is consequences.
A customer pays you. The provider collects it and settles it to your account.
Whose money: Yours. It was your sale.
What that makes you: You are the merchant. You are not providing a payment service to anybody.
You send money to sellers, drivers, affiliates, freelancers, refund recipients.
Whose money: Theirs, or about to be. It is passing through you on its way to someone else.
What that makes you: You are now standing between two other parties, and that is a different activity in law and in the provider's compliance file.
Why the distinction is not pedantry
Indonesian payment providers are licensed by Bank Indonesia as a Penyedia Jasa Pembayaran, and since PBI 23/6/PBI/2021 those licences are organised by activity rather than by product name. That detail is the one that matters here, because remittance, meaning the transfer of funds, is its own listed activity in the category structure. Acquiring, meaning accepting payment on behalf of a merchant, is a different one.
So when a provider offers you a payout or disbursement product, it is not simply exposing another endpoint. It is letting you operate inside a licensed activity it is accountable for. The onboarding requirements it puts in front of you are not bureaucracy it invented. They are the shape of the obligation it is carrying.
That is why the two products can have genuinely different rules at the same provider, and why “X accepts individuals” is an incomplete sentence. It needs the second half: accepts individuals for what?
The line that decides everything, and it is the same line as last time
If you have read the piece on building your own payment gateway, this will look familiar, because it is the same test from the other side. A PJP is defined as facilitating payment transactions for service users, which is to say for other people. The question that decides your licensing exposure is not what you are building. It is whose money passes through you.
Collecting payment for your own sales keeps you comfortably on the merchant side. You are the one being paid. Nothing is being facilitated for anybody else.
Paying out to third parties is where it gets interesting, and the useful thing to understand is that using a licensed provider is exactly how you stay on the right side of it. The provider holds the licence and performs the transfer; you are its customer. That arrangement only works while you are actually inside the product it onboarded you for. The moment the answer to “how are we paying these forty people” becomes a personal bank account and a spreadsheet, the provider is no longer standing there.
The personal account problem is about whose money, not how much
In the thread I mentioned, one person did raise the risk, roughly as: careful, large amounts through a personal account look suspicious. The instinct is right and the reason is wrong, and the wrong reason leads to a bad plan, which is why it is worth separating.
Banks do not run compliance on a number being big. Businesses have big numbers. What draws a review is a pattern that does not match what the account says it is for: many inbound counterparties, rapid in-and-out movement, funds arriving and leaving the same day to people unrelated to the account holder. That is third-party funds flowing through a personal account, and it reads the same at five million rupiah as at five hundred.
This distinction has a practical edge. If you believe the trigger is size, your plan becomes “split it into smaller transfers”, which is worse than the thing you were avoiding and looks exactly like what it looks like. If you understand the trigger is the flow, the plan becomes an entity, or a provider product built for payouts, or fewer hops.
And weigh the failure mode properly, because it is asymmetric. If a payout account is frozen, the thing that stops is not your sales. It is your obligations to other people, on the day they were expecting to be paid.
What to ask, instead of asking which one is cheapest
Fee comparisons are easy to get and are usually the least decisive information available. Below are the questions I would put to every provider on the shortlist, in writing. They are phrased so that a sales reply of “yes, that is possible” does not answer them.
- 01
Is the individual (perorangan) tier available for disbursement, or only for accepting payments?
This is the question the whole thread usually fails to ask. Most answers you will get are about acceptance, because that is the product most people have used.
- 02
What is the destination limit: per transaction, per day, and per unique recipient per month?
Payout products are usually throttled in ways acceptance is not. A limit that is fine in a demo becomes the whole problem on the 1st of the month when everyone is paid at once.
- 03
Which entity is named as the sender on the recipient's bank statement?
If it is the provider rather than your brand, expect support tickets from recipients who do not recognise the transfer. If it is you, expect questions about why a personal name is paying a company.
- 04
What happens to a payout that fails after debit, and how do I see it?
Wrong account number, closed account, name mismatch. The money leaves your balance and comes back later, or does not. If there is no reversal webhook and no reconciliation report, you will find out from the recipient.
- 05
Is there a callback for payout status, signed, or do I have to poll?
Polling a payout API on a cron is how you end up paying someone twice. Ask for the signature scheme in writing, not for a yes.
- 06
What triggers a re-verification or a hold on my account, and what is the process to clear it?
The answer is rarely published. Asking it before you migrate tells you what happens on your worst day rather than your first.
Question four is the one that separates a provider that has thought about payouts from one that has bolted them on. Accepting money has a natural confirmation: the customer is standing there and will complain. A payout has no such feedback loop. It fails quietly, in your favour, on your balance sheet, and against a recipient who may not tell you for a week.
When none of this applies to you
Worth saying plainly, because most of the people asking this question online do not have the problem they think they have.
- If you only take money in, none of the disbursement half applies. Pick on settlement time, channel coverage and integration quality, and stop reading comparison threads.
- If you pay out to fewer than about a dozen people a month, and always the same people, an API is not obviously worth it. Manual transfers plus a reconciliation column is genuinely cheaper, and the honest version of my job is telling you that before you pay me to automate it.
- If the recipients are your own staff, that is payroll, and payroll has its own tools and its own tax handling. Routing salaries through a marketplace payout product is solving the wrong problem with the wrong instrument.
What is left, after those three, is the case that actually needs building: money arriving from many customers, being held for a while, and then leaving to many recipients who are not you. That is a marketplace, and it is a different piece of software from a checkout.
What I have actually built, and what I have not
I have built the hold-and-split shape end to end as a demo: escrow payment intents, a split to the seller, full and partial refunds, signature-verified webhooks, and an automatic release on a schedule. It runs in test mode and it is mine, and you can open it. It is a demo, not a production system carrying other people’s money, and I say that first rather than let it be discovered later.
It is also built on Stripe Connect, which does not support platforms incorporated in Indonesia or Malaysia. That is a real limitation of that demo as proof for an Indonesian platform, and the honest local rails are the ones you already know. The mechanics I care about, the ledger, the idempotency, the exceptions queue, are the same regardless of which provider sits underneath.
What I have not done is take a company through a licence application, and I would tell you that before quoting rather than after.