"Why should an intermediary hold that money first?" Bostjan Korosak of P2Flux on non-custodial payments
4 November 2026 · 12 min read
PSP Dex Interview Series, No. 1 - Guest: Bostjan Korosak, Founder & CEO, P2Flux (operated by Modulout LLC)
Editor's intro
For many merchants, accepting a payment and accessing the money are separate steps. The processor handles settlement, and the merchant waits for a payout. Bostjan Korosak spent 15 years building software platforms and payment integrations, kept running into the limits of that model, and built the alternative. P2Flux is a non-custodial USDC payment platform on Base: payments settle directly into the merchant's own wallet, in the same transaction, with the fee deducted on the way through. No balance held, no payout schedule, no reserve.
He is the first guest in the PSP Dex interview series, and appropriately direct about the trade-offs, including where his own model loses. Below: why he built it, what non-custodial changes day to day, what actually triggers the holds and closures our data says merchants complain about most, how he prices risk, and the one belief about the next three years most of the industry would argue with.
The interview
PSP Dex: You built P2Flux as a non-custodial USDC payment processor. What was broken in the existing options that made you build your own instead of reselling someone else's rails?
The existing payment systems were not necessarily broken. They were built around a model we wanted to challenge.
With traditional processors, businesses are used to applying for an account, passing approval, accepting payments, and then waiting for the provider to release their funds. That model has legitimate reasons behind it, particularly in card payments, where fraud, chargebacks, and consumer protection create financial risks.
But there is another problem that receives less attention: legitimate businesses can struggle to access payment services simply because of the industry they operate in.
Take iGaming as an example. Even licensed operators can face restrictions from banks and payment processors. But the problem extends further. A company developing betting software, supplying sports data, building analytics platforms, or providing technology to the iGaming industry may not accept wagers or handle player funds at all. Yet it can still face additional reviews, account limitations, or rejection because its business is associated with gambling.
Providers such as Stripe have understandable compliance and risk-management obligations. However, broad industry classifications can sometimes create unnecessary barriers for perfectly legitimate software and service businesses.
We experienced the broader challenges of payment integration while building our own software products, and it made us question why businesses should be so dependent on a single provider's approval and continued willingness to process their transactions.
When we started exploring stablecoin payments, we kept asking why we needed to reproduce the same structure on a blockchain. Some crypto payment providers still introduce an intermediary balance or a separate payout process. Recurring payments were another major problem. Accepting a one-time crypto payment is relatively straightforward, but building an actual subscription system where a customer authorizes future payments without manually returning every month is much harder.
We wanted three things: direct settlement to the merchant, genuinely recurring USDC subscriptions, and an integration developers could implement without introducing another layer of financial custody. That became P2Flux.
Our fundamental question was simple: if the technology allows a merchant to receive payment directly, why should an intermediary hold that money first?
We are not trying to eliminate card processors or bypass legitimate regulations. Businesses still need to operate lawfully, regardless of which payment method they use. We are building an independent payment rail that gives legitimate merchants more control over how they receive payments, without requiring a traditional merchant account or leaving their funds in the hands of an intermediary.
"If the technology allows a merchant to receive payment directly, why should an intermediary hold that money first?"
PSP Dex: Non-custodial is your core design choice. What does it change for a merchant in practice, day to day, compared with a custodial processor that holds the balance?
The biggest change is that the merchant stops waiting to receive money they have already earned.
With P2Flux, a customer pays in USDC, and the merchant's share goes directly into their own wallet in the same blockchain transaction. Our fee is deducted in that transaction. There is no P2Flux balance to withdraw, no payout schedule, and no reserve held by us.
Consider a merchant receiving $10,000 in payments. With a custodial provider, some or all of that money may sit with the processor before settlement, depending on the agreement. With our architecture, each successful payment settles directly to the merchant's wallet. That changes cash flow and counterparty exposure. The merchant is not dependent on P2Flux releasing a balance.
However, it also changes responsibilities. The merchant controls their wallet security, reconciles their transactions, and handles refunds from their own funds. We provide payment verification and refund mechanisms, but we cannot reverse a confirmed blockchain payment ourselves.
Non-custodial also does not mean funds are immune from every restriction. Stablecoin issuers, wallet providers, exchanges, and legal authorities can still create limitations in their respective roles.
For merchants comfortable operating with USDC, direct settlement removes a significant operational dependency. For businesses that need immediate conversion to fiat or rely heavily on traditional consumer protections, the benefits need to be weighed against those additional responsibilities.
PSP Dex: Merchants usually meet a payment company at the application form. What do applicants most often get wrong, and what makes an application easy to approve?
From our experience building payment integrations and working with merchants, one common mistake is treating the application as a formality rather than an assessment of how the business actually operates.
A payment provider needs to understand what is being sold, who is buying it, how products or services are delivered, and what happens when something goes wrong. An incomplete website, unclear refund terms, unrealistic transaction estimates, or a business description that does not match the actual product can create unnecessary concerns.
My advice is to be transparent from the beginning. Clearly describe your business model, expected payment volumes, customer locations, delivery process, and refund policy. If your industry has higher dispute rates or unusual transaction patterns, explain them rather than hoping the provider will not notice.
Of course, we approach onboarding differently with P2Flux. A merchant can create a payment link and receive USDC without going through a conventional merchant-account approval process. We do not hold merchant funds or underwrite card chargeback exposure. That does not remove compliance obligations. We screen payer and merchant wallets against sanctions lists and restrict unlawful or abusive use.
I think the broader lesson is that payment providers and merchants both benefit from clarity. A good payment relationship starts with understanding the actual business, not simply checking boxes on an application.
PSP Dex: PSP Dex's data shows account holds and closures are the number one complaint category across fiat processors. From the provider side, what actually triggers a hold or a closure, and what can a merchant do in the first 48 hours that genuinely helps?
We do not operate a traditional card-acquiring risk department, but there are understandable reasons why processors place accounts under review. Common triggers include sudden increases in transaction volume, unusual refund or chargeback activity, suspected fraud, inconsistencies in business information, or concerns about products and services being delivered.
A processor holding funds may be exposed to financial losses if transactions are later disputed. It also has regulatory and contractual obligations. The problem is that a legitimate merchant can experience the consequences of those risk controls before they fully understand what triggered them.
In the first 48 hours, I would focus on three things.
First, establish the exact issue. Ask what triggered the review and what documents or explanations are required.
Second, provide evidence quickly. Transaction records, invoices, proof of delivery, customer communications, and refund information can help establish that the business is operating legitimately. If particular transactions appear suspicious, investigate them and address the underlying problem.
Third, avoid making the situation worse. Opening replacement accounts using misleading information, concealing business activity, or routing suspicious transactions elsewhere can create additional risk.
And I would advise businesses not to wait for an incident before preparing a backup payment method.
This is one reason we believe non-custodial settlement matters. P2Flux cannot impose a reserve or freeze a merchant balance held by us because we never possess that balance. It does not eliminate fraud, legal obligations, or every possibility of service interruption. But it removes one specific risk: having your operating funds sitting inside the payment processor.
PSP Dex: Where do USDC payouts beat bank payouts, honestly, and where do they still lose? Fees, speed, off-ramps, accounting: give us the real trade-offs.
I would actually start by challenging the word "payout." With P2Flux, there is no separate payout. The merchant receives USDC as part of the customer's payment transaction. That distinction matters.
USDC can be particularly useful for international businesses, digital products, software platforms, and merchants who already operate with stablecoins. Settlement can happen around the clock without waiting for banking hours or a processor's payout cycle. On a network such as Base, transaction costs can also be low, although merchants must consider the payment provider's service fee separately. P2Flux also lets customers pay network fees in USDC, so they do not need to hold ETH just to complete a checkout.
But there are real disadvantages. If a merchant's expenses are entirely in euros or dollars in a bank account, they may need an off-ramp. That introduces conversion fees, exchange spreads, banking relationships, and potentially additional compliance checks.
Accounting is another important issue. Blockchain transactions provide verifiable records, but merchants still need to connect those transactions with invoices, customer orders, refunds, and tax reporting.
There is also operational risk. Sending assets to an incorrect wallet or network can result in an irreversible loss. Wallet security becomes a business responsibility. And traditional banking should not be underestimated. Domestic transfers and systems such as SEPA Instant can already be inexpensive and very fast.
I would not recommend USDC simply because it is crypto. I would recommend it when the merchant benefits from direct settlement, international reach, programmable payments, or the ability to retain and use USDC without immediately converting everything into fiat. The comparison should be the total cost and operational complexity of receiving usable funds, not just the advertised transaction fee.
PSP Dex: You serve merchants many processors will not touch. How do you price risk without becoming the expensive option, and where do you draw your own line on who you will not onboard?
I would make an important distinction here: our objective is not to become a payment provider for businesses that others reject for legitimate legal or compliance reasons. Our objective is to give legitimate businesses another payment architecture.
Traditional card processors price several risks, including chargebacks, fraud exposure, and the possibility of losses on merchant balances. Some manage those risks through reserves, delayed settlement, or higher fees. Our model is different because P2Flux does not hold merchant funds or provide a credit facility. We charge for payment infrastructure, verification, and execution rather than taking custody of a merchant's revenue.
Our standard pricing is 1% for successful one-time payments and 2% plus $0.10 for subscription renewals, with applicable network costs handled separately. We do not charge monthly account fees or payout fees. That transparency is important to us.
But non-custodial does not mean accepting everything. We screen payer and merchant wallets against OFAC sanctions lists. We prohibit unlawful activity, fraud, sanctions violations, and abuse of our infrastructure. Where necessary, we can restrict access to our services. Merchants also remain responsible for their own regulatory requirements, customer protection, refunds, and taxes.
If a business cannot legally operate, accepting USDC does not suddenly make that business legitimate. We want to reduce unnecessary payment friction, not remove accountability.
PSP Dex: If a merchant could keep only one piece of redundancy in their payment setup, what should it be: a second processor, a non-custodial rail, a backup bank account, or something else?
I would choose a genuinely independent payment rail.
A second processor can be useful, but if both processors depend on similar banking infrastructure, acquiring relationships, or underlying restrictions, the merchant may discover that the supposed backup has the same weaknesses as the primary system.
The important question is not how many payment providers you have. It is how many independent ways you have to continue receiving money.
For a digital business with international customers, I think a non-custodial USDC option can be a particularly valuable backup. If a card processor becomes temporarily unavailable, customers who can pay with USDC still have a way to complete purchases, and those payments settle directly to the merchant's wallet.
That said, if nearly all your customers pay by card and have no interest in using crypto, an independent second card acquirer may be the more practical choice. The backup must match the customers and the business. It also needs to be tested before an emergency. A backup payment option that nobody knows how to operate is not particularly useful.
My rule would be: diversify the dependency, not just the provider's logo.
PSP Dex: What is the one thing you believe about payments in the next three years that most of the industry would disagree with?
I believe that some of the most important payment infrastructure businesses in the next three years will not handle merchant payouts at all.
Today, the industry largely assumes that accepting a payment and receiving the money are two separate events. A customer pays, the processor receives or accounts for the funds, and the merchant gets settled later. I think that separation will become unnecessary for a growing category of digital commerce.
With programmable stablecoins, payment authorization, execution, verification, and settlement can happen as part of the same process. The infrastructure provider can earn revenue for making that process reliable without holding the funds.
And I believe AI agents will accelerate this change. When software starts paying other software for API calls, content, computing resources, and services, the traditional payment model becomes less natural. An AI agent does not necessarily need a card checkout, a merchant account dashboard, or a three-day payout schedule. It needs authorization, spending limits, verifiable settlement, and infrastructure that other systems can integrate with.
I do not think credit cards will disappear, or that every consumer will start paying with a crypto wallet by 2029. But I do believe the role of a payment processor will increasingly shift from controlling the movement of money to providing the software that makes direct payments possible.
That is the future we are building toward with P2Flux.
Links
- P2Flux: https://p2flux.com/
- Technical documentation: https://p2flux.com/docs/

