The only payment infrastructure
with a published account safety policy.

Accounts are frozen for abuse or non-payment. Those are the two conditions. Your processor choices, your pricing, your merchant relationships: all of that stays yours.

Two conditions. That's the entire list.

Value.IO freezes accounts for two reasons:

Abuse means one of the following:

  • You misrepresented your business during onboarding
  • You violated the terms you agreed to when you got access
  • You're using the infrastructure for purposes other than what you disclosed

If you told us who you are, what you're building, and what your business does, and that's what you're actually doing, this condition does not apply to you.

Non-payment means what it says. You owe us money and you haven't paid it.

That's the policy. Not a summary. The whole thing.

What does not trigger a freeze

This is the list that matters. None of the following will result in your account being frozen:

A change in your transaction volume, up or down
The type of merchants you work with, within your disclosed business model
A chargeback rate that fluctuates
A new vertical you're expanding into, consistent with what you disclosed
Your choice of acquiring bank or processor relationship
Your pricing to merchants
Your revenue model
Seasonal spikes or irregular processing patterns
A competitor complaining about you
An algorithm flagging your account
An internal policy change we didn't tell you about
A risk review triggered by nothing you did

There is no algorithmic risk scoring running in the background. There are no opaque policy triggers. There are no unilateral surprises.

If you're not abusing the platform and you're paying your bills, you stay online.

Why This Matters

Most payment infrastructure operates on a model of discretionary access. Somewhere in the terms of service, usually in a clause few people read until it's too late, is language that gives the provider the right to terminate or freeze your account for reasons that are never fully enumerated. "At our discretion." "As we determine appropriate." "In response to risk signals." What those signals are, who reviews them, and what you can do about it: undefined.

That's not a legal quirk. It's a feature. Discretionary termination rights give providers maximum flexibility to exit relationships that become inconvenient. When your platform starts processing significant volume, you become visible. When you become visible, the calculus changes. Developers who built on a platform under one set of expectations have found themselves frozen under a different set, often with little notice and no clear path to resolution.

A published account safety policy changes the operating agreement. It names the conditions. It binds both sides. When Value.IO agrees to take a business on, that commitment is backed by a policy that's visible to everyone, not just to whoever is reviewing your account on a given Tuesday. You know the rules. We know the rules. That's the foundation everything else is built on.

How Onboarding Works

Value.IO reviews every application before granting access.

This isn't a checkbox process. We're establishing fit: your business model, your use case, your merchant base, what you're building. If the infrastructure is right for what you're doing, you get access. If it's not, we'll tell you.

The qualification review is where the safety policy begins. Both sides agree to work together based on a shared understanding of what that means. Once we've accepted your application, the terms are clear: build what you said you'd build, pay your fees, and your infrastructure stays stable.

The selectivity protects you. A provider that accepts everyone has no basis for the policy that follows. We review applications precisely because we intend to honor our commitments to the developers we take on. That's not friction. That's how a commitment works.

What "Your Card Data Is Yours" Means

Value.IO operates a PCI Level 1 certified card vault as independent infrastructure. The card data your platform collects, payment credentials, tokenized customer records, stored instruments, lives in that vault, not inside a processor relationship.

Processor changes don't touch your vault. If your acquiring relationship changes, gets renegotiated, or moves to a different bank, the card data stays where it is. You don't re-collect. Your customers don't re-enter their cards. Your recurring billing keeps running. Because Value.IO's Network Tokens stay valid across card reissues and replacements, subscription revenue doesn't leak when cards change either.

Three layers of card resilience, running simultaneously. Value.IO stores Network Tokens (Visa/Mastercard-issued tokens that update automatically when underlying cards change), PAN (the actual card number as a permanent fallback), and runs Account Updater services. If a Network Token fails to update, Account Updater refreshes the stored PAN. If Account Updater has a gap, the PAN is still there. We use every tool available to keep your stored card data current, because the job isn't done until the payment works.

Your card data isn't held hostage to the relationship. In the event of any disruption to your account, for any reason, the card data stored in Value.IO's vault belongs to your platform. It's not collateral. It's not negotiating leverage. It's yours.

Portability is structural, not a courtesy. Because the vault is separate from the processing layer, you're not locked into a single payment path by the location of your customer data. You can route transactions, switch processors, or bring on new acquiring relationships without migrating cards.

For a platform operator, this is the difference between owning your payment infrastructure and renting someone else's. Your card data is the most valuable asset in your payment stack. It should be under your control.

Infrastructure you can build on. Not around.

Payment infrastructure should be predictable. You've read the policy. You know what it takes to stay online. Apply for dev access and start building with infrastructure that won't move the goalposts.