One platform for the whole commerce chain
Commerce infrastructure, not a merchant account.
Most providers sell you an account and lock the stack to it. High Wire runs underwriting, checkout, routing, fraud, disputes, payouts, and a reconciled ledger across every processor you use, including the MIDs you already hold.
Platform
One platform, from underwriting to reconciliation.
Onboard the merchant, accept the payment, screen it for fraud, route it for approval and cost, handle the disputes, pay out, and reconcile every dollar against the bank. Every stage runs on one merchant record and one API, and shows up in the same portal.
Get approved and boarded.
Apply once. We verify the business and everyone behind it, then board it onto PSPs that fit, or connect the MIDs it already has.
- KYC and KYBOwners and entity
- PSP boardingAppetite matched
- Sub-merchantsOnboard by API
- Bring your own MIDExisting accounts
- Merchant monitoringAfter go-live
Case HW-24817, supplementsApproved
Take payments your way.
Launch a hosted checkout in one API call, embed it in your page, or build your own form on the API with the same screening underneath.
- Hosted checkoutOne API call
- Embedded checkoutInside your page
- API checkoutYour own form
- Wallets and pay laterHigher conversion
- Payment links and invoicesNo code needed
- SubscriptionsDunning and retries
- In personCard present
Stop fraud. Win disputes.
Every payment is scored with device and behavior signals, including API checkouts through the risk SDK. Disputes arrive with evidence already gathered.
- Fraud screeningEvery checkout type
- 3D SecureSCA exemptions
- Rules and backtestingShadow mode
- Ratio monitoringNetwork programs
- Dispute alertsBefore chargebacks
- RepresentmentEvidence assembled
Approve more. Pay less.
Route each payment across your MIDs and ours by approval rate, cost, and card type, and retry soft declines on the next processor automatically.
- Network tokensPortable across MIDs
- Card account updaterFewer declines
- Adaptive retriesBy decline code
- Cost-based routingCost, BIN, region
- Level 2 and 3 dataB2B interchange
- Bring your own MIDRoute across all
Pay out on your schedule.
Send payouts to merchants, sellers, and agents by ACH, instant transfer, or wire, hold balances, and issue cards with spend controls.
- PayoutsACH, instant, wire
- Balances and reservesVisible to merchants
- Split paymentsMarketplaces
- Multi-currencyAnd FX
- Card issuingVirtual and physical
- YieldOn idle balances
Close the books faster.
Follow every dollar from authorization to payout, match settlements automatically, and give every role its own portal.
- ReconciliationSettlement matching
- ReportingExports and warehouse
- Roles and audit logsMulti-entity
- AnalyticsBy processor and BIN
- PortalsMerchant, agent, platform
- Tax and remittanceWhere collected
Product visuals use sample data
Hosted checkout
A checkout your customers already trust.
Launch in one API call. Wallets, pay later, and saved cards are built in, every payment is screened, and it looks like your brand.
- Wallets and pay laterApple Pay, Google Pay, PayPal, and Klarna alongside cards.
- Your brandYour logo, your colors, and a checkout domain of your own.
- Screening built inEvery payment is scored before it reaches a processor.
- Hosted, embedded, or APIStart hosted and move deeper when you need more control.
Pay Northwind Nutrition
Express checkout
Klarna
Split $72.00 into 4 payments.
Payment successful
$72.00 paid to Northwind Nutrition
- Screened, risk score 1218 ms
- 3D Secure, frictionless34 ms
- Routed to PSP B41 ms
- Authorized and captured348 ms
- Receipt sent to mary@example.com352 ms
Interactive sample. Wallet and pay-later buttons are placeholders for each provider's official button.
Products
Everything between the application and the bank deposit.
Board gets a business underwritten and live. Route, Lift, and Vault win more approvals and keep cards working when the processor changes. Screen, Margin, and Ledger defend the money after the sale, from fraud and disputes to interchange, fees, and proving every dollar against the bank. Agents do the parts nobody has time for.
KYC and KYB done up front, then submitted to the acquiring partners whose appetite fits the business.
Routemulti-processor orchestrationOne integration across every processor you use, with failover when one stops answering.
Liftacceptance suiteNetwork tokens, card account updater, adaptive retries, and cascading, working on the same payment.
Vaultportable tokensStored cards that belong to you, chargeable on any processor you are boarded with.
Margincost and interchangeLevel 2 and 3 data, surcharging and dual pricing, cost-based routing, and fee variance checking.
LedgerreconciliationEvery lifecycle event proved daily against processor settlement files and bank deposits.
Screenfraud and disputesDevice and behavior screening on every checkout type, with disputes prepared before the deadline.
AgentspreviewSpecialist agents that approve applications, route payments, and assemble dispute evidence.
Ledgering and reconciliation
One ledger. Every dollar accounted for.
Transactions, settlements, fees, refunds, reserves, disputes, and bank deposits all land in one ledger and are matched automatically. Every figure on a statement traces back to the event that caused it.
High Wire ledger
- Captures$128.4M
- Refunds$2.1M
- Chargebacks$184.2k
- Fees$3.42M
Processor settlement
- Gross$128.4M
- Adjustments$2.3M
- Interchange$2.18M
- Net funding$122.9M
Bank deposit
- ACH credits$120.8M
- In transit$2.1M
- Reserve held$1.24M
- Returns$38.4k
Matched
99.94%
4,231 batches, 12 exceptions open, day closed at 06:14 UTC
Sample figures. A day is not closed until all three agree.
Every processor settlement file is parsed and matched line by line against the ledger. Nobody opens a spreadsheet to close a day.
Authorizations, captures, refunds, fees, reserves, disputes, and payouts all recorded against one payment ID, with the fee breakdown attached.
Bank credits are tied back to the settlements that produced them, so you know a deposit is right before you spend against it.
Short-funded batches, fee variances, duplicate refunds, and returned payouts surface as exceptions with an owner and an age, instead of quietly shrinking a payout.
Multiple MIDs and processors settle on different schedules in different formats. The ledger normalizes them into one financial record that survives a switch.
A close checklist per entity and per processor, with journal entries exported to your accounting system as CSV or through the API.
Every transaction accounted for. Every settlement reconciled.
Built for
Your business, your portfolio, your platform, or your bank.
Merchants take payments directly. Agents and ISOs board and manage portfolios. Platforms embed payments in their own products. Banks and processors take merchants we have already underwritten.
Merchants
Get boarded, take payments on a hosted checkout, and run the business from your merchant portal.
- Hosted checkout with wallets and pay later
- Portal for payouts, disputes, and reports
- Get boarded or bring your own MID
Agents and ISOs
Refer and board merchants, follow every application, and earn residuals on the portfolio you build.
- Agent portal with portfolio performance
- Lead submission and onboarding status
- Residual statements and risk alerts
Platforms
Embed onboarding and payments in your software under your own brand, and manage every sub-merchant from one console.
- White-label checkout and merchant portal
- Sub-merchant KYC, KYB, and boarding
- Platform console across all accounts
Banks and processors
Take merchants we have already underwritten, matched to your appetite, with monitoring that continues after boarding.
- Appetite and compliance matching
- Enterprise pre-underwriting in one file
- Ongoing monitoring and reconciled reporting
Portals
A portal for everyone on the platform.
Merchants, agents, and platforms each get a workspace built for their job, running on the same live data.
Good afternoon, Maya
Aurelia & Co, month to date $892,410
Keystone portfolio
Agent ISO-KMS-001, 412 merchants, Diamond tier
| Merchant | Volume, 30d | Approval | Risk | Residual |
|---|---|---|---|---|
| ChronoLuxe Timepieces | $14.2M | 95.2% | A | $18,420 |
| Aurelia & Co | $8.92M | 93.8% | A− | $11,596 |
| Kestrel Studios | $7.14M | 94.0% | A | $9,282 |
| Seabright Outfitters | $4.24M | 91.2% | B | $5,512 |
| Ferndale Pharma | $3.94M | 93.1% | A | $5,122 |
Northstar Booking
Platform account, 186 sub-merchants, white-label
| Sub-merchant | KYB | Status | Volume, 30d |
|---|---|---|---|
| Fieldnote Courses | verified | Live | $412,380 |
| Cedar Telehealth | in review | Onboarding | — |
| Harbor & Pine Goods | verified | Live | $288,915 |
| Lumen Coaching Co. | docs needed | Onboarding | — |
| Atlas Software Inc. | verified | Boarded | $0 |
Portal previews use sample data
Agentic commerce Preview
Specialist AI agents on every onboarding, payment, and dispute.
Two engines of collaborating agents make decisions in real time, explain each one, and learn from outcomes. An oversight agent tunes thresholds within guardrails, and your team stays in control of anything significant.
Agents check documents, ownership, and websites in parallel, approve clean applications, and send edge cases to your team.
decision agent: 2 amber flags, sent to reviewEvery routing decision records its reasoning and confidence, so operators can review or override it.
route PSP A: issuer approval higher, 0.94The retry agent re-sends soft declines to the next processor, using a network token where it helps.
retry agent: recovered on PSP B in 658 msEvidence is gathered from authorization, 3D Secure, device, and delivery records, and a rebuttal is drafted for your review.
disputes agent: 6 of 7 evidence items attachedThe oversight agent proposes limit and risk changes. Small ones apply within guardrails, and larger ones wait for approval.
proposal: velocity limit +8%, appliedNew models run in shadow against live traffic and must pass a quality gate before they're promoted.
challenger in shadow, day 6 of 14Underwriting
The platform is what gets complex merchants approved.
Partners see a portfolio that is already screened, reserved, and reconciled, not a form filled in once at signup. Appetite differs by partner, so a file goes to the acquirer it actually fits.
Fraud screening, dispute handling, reserves, and reconciliation run on every transaction we board. Risk is measured continuously instead of guessed once at signup, and the partner can see it.
Appetite differs by partner and by category. A file goes to the acquirer whose appetite fits it, underwritten up front in the format they accept, instead of the one that happened to receive it.
Categories are samples. See what underwriting looks for.
Developers
An API your engineers will enjoy.
Create hosted checkout sessions, authorize and capture payments, and follow every payment by a single ID.
- auth
- HTTP Basic, server-side keys
- format
- REST and JSON, amounts in cents
- retries
- Idempotency-Key, 24 hours
- environments
- Sandbox and live
curl -X POST "$HIGHWIRE_API/v1/payments/checkout-session" \ -u "$HIGHWIRE_KEY:$HIGHWIRE_SECRET" \ -H "Content-Type: application/json" \ -d '{ "lineItems": [{ "name": "Annual membership", "amount": 7200, "quantity": 1 }], "customerEmail": "mary@example.com", "successUrl": "https://northwind.example/done?session_id={CHECKOUT_SESSION_ID}", "cancelUrl": "https://northwind.example/cart" }' # Returns a sessionUrl. Redirect the customer to pay.
curl -X POST "$HIGHWIRE_API/v1/payments/auth-and-capture" \ -u "$HIGHWIRE_KEY:$HIGHWIRE_SECRET" \ -H "Idempotency-Key: 9f6a2c58-3d1e-4b7a-8c2f-5e1d4a9b0c3e" \ -d '{ "amount": 7200, "cardNumber": "5555555555554444", … }' { "paymentId": "01928e3e-7b6c-7c8e-9b3a-5b9f8b9b9b9b", "status": "CAPTURED", "amount": 7200 }
Questions we get in the first call.
The short answers are here. The ones that turn on your category, your volume, or the processor you already use come from a person on the first call.
Why not go to a processor directly?
You can, and some merchants should. High Wire is worth it when approval is uncertain, when one processor is a single point of failure, or when you need one set of books across several of them. We do the underwriting once and submit it to partners whose appetite matches your business.
What happens if a processor declines me?
Your file goes to another partner without starting over. Nothing about your integration changes, because you built against High Wire rather than against a processor.
Can I keep the merchant account I already have?
Yes. Connect existing MIDs alongside any we board for you. Checkout, screening, disputes, reconciliation, and payouts work the same across all of them, and routing rules decide which one takes each payment.
How long does boarding take?
It depends on the category and how complete the application is. We publish a median time from application to live MID, and your agent or account contact can tell you what to expect for your profile.
How do reserves work?
Where a partner requires a reserve, the amount, type, and release schedule are visible in the portal and in the ledger from day one, not discovered at payout time.
Do you work with high-risk categories?
We underwrite businesses that many processors decline, which is why the underwriting work happens before anyone is asked. Some categories remain out of scope, and we will tell you that early rather than after you have integrated.
Do we have to use the whole platform?
No. The products are modular, and the set that applies can differ from one transaction to the next, because the acquiring rail a payment runs on determines which features are available to it. Add or remove pieces as your mix changes, without reintegrating.
Can we run this for the merchants we manage?
Yes. The same platform deploys for a single merchant or white-labeled for a platform, agency, or office managing hundreds of them. Your merchants get checkout and portals under your brand, and you get boarding, routing, and reconciliation across the whole portfolio.
Launch your commerce platform.
Tell us what you're building. We underwrite the business, connect the processors and payment methods it needs, and hand over one API, one ledger, and a portal for everyone who touches it. Agents and platforms get their own from day one.
High Wire Ledger
Products / Operate
High Wire LedgerReconciliation across the full payment lifecycle
Every event in the payment lifecycle is written to a ledger, then proved every day against settlement files from processors and deposits from the bank. When the numbers disagree, you hear it from us first.
Balanced against an outside source, not against ourselves.
A three-way match runs daily. Our ledger, the processor's settlement file, and the money that actually landed in the bank all have to agree before a day is closed.
High Wire ledger
- Captures$128.4M
- Refunds$2.1M
- Chargebacks$184.2k
- Fees$3.42M
Processor settlement
- Gross$128.4M
- Adjustments$2.3M
- Interchange$2.18M
- Net funding$122.9M
Bank deposit
- ACH credits$120.8M
- In transit$2.1M
- Reserve held$1.24M
- Returns$38.4k
Matched
99.94%
4,231 batches, 12 exceptions open, day closed at 06:14 UTC
Sample figures
Every state, on one payment ID.
The ledger records the whole lifecycle, not just the sale. Each entry carries the payment ID, the merchant, the processor, and the fee breakdown, so any number on a statement can be traced back to the event that caused it.
| Lifecycle event | What the ledger records |
|---|---|
| Authorization | Amount, processor, MID, approval or decline reasonNo money moves yet, but the intent is recorded |
| Capture | Captured amount, currency, timestamp, batch |
| Refund | Full or partial, original payment ID, fee treatment |
| Chargeback and reversal | Case ID, reason code, amount held, representment outcome |
| Fees | Interchange, scheme fees, processor markup, High Wire feeExpected versus actual, per transaction |
| Reserve | Rolling or fixed, amount held, scheduled release |
| Payout | Net amount, rail, bank reference, arrival date |
| Adjustment | Corrections, recoveries, write-offs, with a reason and an owner |
Exceptions come to you, with the reason attached.
Anything that doesn't match becomes a worked item with an owner, an age, and a resolution. Nothing is silently written off.
Sample exception queue
What you get out of it.
Merchant statements, agent residual statements, and platform fee reports all come from the same ledger, so they agree with each other and with the bank.
A close checklist per entity and per processor, with journal entries exported to your accounting system as CSV or through the API.
Fee variances, short-funded batches, duplicate refunds, and missed recoveries surface as exceptions instead of quietly reducing a payout.
Multiple MIDs and processors settle on different schedules and formats. The ledger normalizes them into one set of books.
Every entry is immutable and traceable to a source document, which is what auditors, partners, and sponsor banks ask for.
Rolling reserves, holds, and scheduled releases are visible to the merchant and the agent, which removes most support tickets about missing money.
Stop closing the books by hand.
Tell us what month-end looks like today, and we will show you what it looks like when every day is proved against the bank.
High Wire Route
Products / Optimize
High Wire RouteEverything a processor gives you, across every processor
A gateway, a vault, wallets, fraud tools, disputes, settlement, and a portal. One processor gives you all of that, locked to them. High Wire gives you the same set across every processor you use, including the MIDs you already hold.
The same capabilities, without the lock-in.
This is the full picture of what a payment service provider delivers, and what changes when the same capability runs across several of them at once.
| Capability | With a single processor | With High Wire orchestration |
|---|---|---|
| Gateway and APIs | One integration, their API, their versioning | One integration for all processors. Add or replace a processor without touching your code |
| Checkout | Their hosted page or elements | High Wire Checkout, High Wire Components, or API checkout, the same on every processor |
| Card vault and tokens | Tokens that belong to that processorMoving means a migration project | One vault, tokens usable across processors, so cards keep working when routing changes |
| Wallets and local methods | Whatever they support in each market | The combined coverage of every connected processor |
| Approval optimization | Their retries, network tokens, and account updater | All of that, plus cascading retries to a different processor when one declines |
| Fraud and 3D Secure | Their engine, their rules, their scores | Your rules applied consistently everywhere, including on API checkouts through the SDK |
| Disputes | Their console, their evidence format, their deadlines | One queue across processors, with evidence assembled and deadlines tracked in one place |
| Settlement and funding | Their report, their schedule, their format | One reconciled ledger across every processor, proved against the bank |
| Merchant management | Their portal, per processor | One portal for merchants, agents, and platforms across all processors |
| Underwriting and boarding | Apply to each one separately, from scratch | Underwritten once by High Wire and submitted to the partners that fit |
| If they go down | You wait | Traffic fails over to another processor automatically |
| If they decline you | You start again somewhere else | Your file goes to a partner whose appetite matches your profile |
Why this matters commercially.
Route by issuer performance, card type, and region, then retry soft declines on a second processor instead of losing the sale.
Processor outages, sudden risk decisions, and account reviews stop being existential when volume can move the same day.
Send each transaction to the processor with the best economics for that card and market, and see the difference in the ledger.
When switching costs are low, pricing conversations with processors change. Your volume is portable and they know it.
Every processor settles differently. The ledger normalizes them so finance closes once, not once per provider.
Adding a processor, a market, or a payment method is a configuration change, not another integration project.
Bring the MIDs you already have.
Connect existing merchant accounts alongside the ones we board for you. The same checkout, screening, disputes, and ledger apply to all of them, and routing rules decide which one takes each payment.
If a processor declines you later, or your volume outgrows them, the rest of the platform doesn't change.
Sample routing data
Add a processor without a project.
Bring the MIDs you already hold and route the next payment to whichever one is performing.
High Wire Board
Solutions / Acquiring partnerships
High Wire BoardUnderwriting and acquiring partnerships
High Wire sits between merchants who need to get approved and the banks and processors who decide. We underwrite up front, in a format partners accept, and we stay accountable for the portfolio afterwards.
Underwritten before anyone says no.
Most declines happen because an application arrives thin. We do the work first, in the same structure every time, so partners are deciding on a complete file instead of guessing.
That means fewer instant declines at signup, and fewer accounts closed a few weeks later when the processor finally looks closely.
A consistent, complete file underwritten to the partner's standard means fewer instant declines and fewer accounts frozen weeks after boarding.
You are not an unknown business emailing a bank. You arrive inside a portfolio the partner already works with, with monitoring they already trust.
Whichever partner approves you, you process on the integration you already built. No second build, no second certification.
If one partner's appetite doesn't fit, your file goes to another without starting over. Many merchants end up boarded on more than one.
We watch the things that get merchants terminated, including chargeback ratios, content changes, and volume spikes, and flag them before the partner does.
As volume grows, adding processors is a routing change. Your pricing conversations improve, and your risk of a single decision drops.
Merchants matched to your appetite, not thrown at it.
Every partner has a different risk appetite: categories they want, categories they won't touch, geographies, volume bands, chargeback tolerance, and compliance requirements. We hold those rules and route applications accordingly.
You see fewer applications, and a higher share of them are ones you would have approved anyway.
Northwind Nutrition LLC
- CategorySupplements
- GeographyUS, CA
- Projected volume$1.2M / yr
- Average ticket$72
- Chargeback history0.31%
- Risk tierMedium
Categories, geographies, volume bands, prohibited lists, and licensing requirements are held per partner and applied before anything is submitted.
Identity, KYB, beneficial ownership, sanctions screening, website and content review, projected volumes, and processing history, delivered as one structured file with evidence attached.
Monitoring continues after boarding: ownership and content changes, velocity and volume shifts, chargeback ratios against thresholds, and reserve recommendations, shared with you.
Fewer declines to process, less early attrition, fewer surprise losses, and a merchant base whose behavior is already being watched.
Merchants integrate with High Wire, so onboarding new merchants onto your rails does not require new integration work on either side.
Settlement, fees, reserves, and payouts are reconciled daily against your files, so disputes about numbers are resolved with evidence.
Partner names are withheld here. Replace with named partners where agreements permit.
Send us a category you keep declining.
We will tell you whether we can underwrite it, and what the file looks like by the time it reaches you.
Company / Pricing
Pricing
Pay per transaction, with no setup or monthly fee on the standard plan. Custom pricing, including interchange plus, is available at volume or where a risk profile calls for it.
Standard
For merchants getting boarded and processing on High Wire, with no setup fee, no monthly fee, and no cancellation fee.
- KYC, KYB, and boarding onto matched partners
- High Wire Checkout, Components, and API checkout
- Fraud screening and 3D Secure
- Disputes, reconciliation, ledger, and payouts
- Merchant portal and developer sandbox
Custom
For higher volume, multi-processor routing, platforms with sub-merchants, agents and ISOs with portfolios, and businesses whose risk profile needs specific terms.
- Volume and interchange-plus pricing
- Orchestration across your MIDs and ours
- Agent residual and platform revenue share
- Reserve terms set per profile
- Named implementation and risk contacts
| Online card paymentDomestic, standard plan | 2.9% + $0.30 |
| In-person card payment | 2.7% + $0.05 |
| Manually keyed card | 3.4% + $0.30 |
| ACH direct debit | 0.8%, capped at $5.00 |
| Instant bank payments | 2.6% + $0.30 |
| Pay laterRates vary by provider and market | 5.99% + $0.30 |
| International cardAdded to the standard rate | +1.5% |
| Currency conversion | +1.0% |
| KYC and KYB at applicationIncluded for merchants boarding through High Wire | Included |
| Ongoing merchant monitoring | Included |
| Fraud rules and device screeningPer screened transaction | $0.02 – $0.07 |
| 3D Secure authentication | $0.03 |
| DisputeReturned if the dispute is won | $15.00 |
| Early dispute alert | $29.00 |
| Orchestration across processorsRouting, retries, and failover across your MIDs and ours | Custom |
| Level 2 and 3 data, surcharging, and cost toolsSee High Wire Margin | Included |
| Bring your own MIDConnect an existing merchant account | Custom |
| Platform and sub-merchant accounts | $2.00 / month + 0.25% + $0.25 per payout |
| Standard payout | Included |
| Instant payout | 1.5% |
| Recurring billing | 0.7% of billing volume |
| Tax calculation and filing | 0.5% per transaction |
| Reconciliation, ledger, and statements | Included |
Why is some pricing custom?
Risk profile drives cost. Categories with higher chargeback exposure carry different terms, and reserves are set per merchant. Routing across several processors also depends on which partners you are boarded with.
What is a reserve?
A portion of settlement held for a period to cover chargebacks and refunds. It is shown in the portal and in the ledger, with the scheduled release date visible to you and your agent.
How do agent and platform economics work?
Agents and ISOs earn residuals on their portfolio, paid monthly with a statement generated from the same ledger. Platforms can add their own fees on top of High Wire's, collected automatically.
Do you charge to board a merchant?
Boarding through High Wire is included on the standard plan. Where a partner requires specific underwriting work or documentation, any fee is agreed before submission.
Get a rate for your actual volume.
Published rates are a starting point. Card mix, ticket size, and category all move the number.
High Wire Screen
Products / Protect
High Wire ScreenFraud screening and dispute work on every checkout you run
Every payment is scored on device and behavior signals before it is authorized, including the checkouts you build yourself. When a dispute arrives anyway, the evidence is already gathered and the deadline is already tracked.
Scored before the authorization leaves.
Signals are collected on every checkout type, your rules run against them, and the payment takes one of four paths. The same rules apply on every processor you are boarded with, so behavior does not change when routing does.
What we look at
- Device fingerprintEvery session
- Behavior in sessionTyping, paste, speed
- Email and phone ageReputation
- Card and BIN historyAcross the network
- VelocityCard, device, address
- Geo and IPMismatch scoring
Screening runs before the authorization, so a blocked payment never reaches your chargeback ratio.
Including the checkouts you build yourself.
Most providers screen their own hosted page well and leave your API integration exposed. The risk SDK sends the same device and behavior signals from your own interface, so one set of rules covers everything you sell through.
| Checkout type | What runs on it |
|---|---|
| Hosted checkout | Full screening, 3D Secure, and device signals with nothing to build |
| Embedded components | The same rules, running inside your own page and your own styling |
| API checkout | Device and behavior signals through the risk SDKYour interface is screened the same as ours |
| Wallets and local methods | Scored per method, on the same rule set as cards |
| Subscriptions and rebills | Renewals scored separately from the first payment, so a good customer is not blocked at month four |
| Agentic checkout | Agent-initiated payments carry their own signals, limits, and mandatePreview |
Disputes arrive with the evidence already attached.
Alerts are worked before they become chargebacks where the network allows it. Anything that gets through is assembled into a representment with the order, the delivery proof, and the screening record from the original payment.
Sample dispute queue
Losses down, approvals intact.
Screening runs ahead of the authorization, so blocked attempts never touch the chargeback ratio that decides whether you stay boarded.
3D Secure is applied where it raises approval and skipped where an exemption applies, instead of being switched on for everyone.
Every case carries its filing date. Evidence is assembled as the dispute arrives, not in the last few hours before the window closes.
The same rules run on hosted checkout, embedded components, and your own API integration, across every processor you use.
Chargeback and fraud ratios are tracked against the network program thresholds, with warning before you cross one rather than after.
New rules run in shadow mode against live traffic and backtest against your history, so you see what a change would have blocked before it blocks anything.
See what your rules would have blocked.
New rules backtest against your own history and run in shadow mode before they decline anything.
High Wire Payout
Products / Payout
High Wire PayoutBalances, rails, and cards, on your schedule rather than the processor's
Money that has settled should not sit still while it waits for a batch window. Hold balances, pay out on the rail that fits each case, split across sellers, and issue cards against the balance, all from the same record the ledger reconciles.
Pick the rail per payout, not per platform.
Most providers give you one payout schedule and one rail. Each payout here chooses its own, so a weekly settlement to a merchant and an instant payout to a seller who just delivered are the same product with different terms.
Every movement lands in the ledger as it happens, which is why a payout can be traced back to the transactions that funded it.
| Rail | Speed | When it fits |
|---|---|---|
| ACH | 1–2 days | Standard scheduled settlement, lowest cost per payout |
| Same-day ACH | Same business day | Cutoff-driven runs where next-day is too slowPer-transaction limits apply |
| Instant | Seconds | Sellers, drivers, and contractors paid on completionRTP and FedNow where the receiving bank supports it |
| Wire | Same day | Large single payouts and cross-border settlement |
| Multi-currency | Varies by corridor | Holding and paying in the currency collected, with FX at the point of conversion |
| Card | Immediate | Spending against the balance directly instead of paying out first |
What changes when you hold the balance.
Settled funds sit in a balance you control, so you can pay out, split, spend, or hold rather than taking whatever schedule a processor assigns.
One payment funds several parties. The split is recorded at capture, so each seller's share is known before the money moves.
Amount held, reason, and release date are shown to the merchant and the agent from day one, which removes most of the support tickets about missing money.
Virtual and physical cards with spend limits and category controls, funded by the balance rather than by a separate transfer and a separate account.
Balances held between settlement and payout can earn rather than sitting flat, with the terms stated up front.
Every payout carries its rail, bank reference, and arrival date into the ledger, so a deposit can be matched to the transactions that produced it.
Move money on your schedule.
Tell us how often money needs to move and to whom, and we will show you which rails fit.
Solutions / Merchants
For merchantsGet approved, go live, and still be live in a year
Getting approved is the hard part. Staying approved is harder. One application, underwritten properly, gets you boarded with a partner that actually fits, and the same platform then runs the checkout, the screening, the disputes, and the payouts.
From application to first payout.
Most of the work is ours. What you do at each stage is short, and it does not repeat every time a processor changes.
| Stage | What you do | What we do |
|---|---|---|
| Apply | Tell us about the business and the people behind it, once | Verify identity, registration, and history against the evidence your category needs |
| Underwriting | Send what we ask for, and nothing we did not | Build the file in the structure partners accept, before anyone is asked |
| Matching | Nothing | Submit only to partners whose appetite fits the profileIf one says no, the file moves rather than starting again |
| Going live | Drop in hosted checkout, or call the API | Issue the MID, configure routing, and connect any MIDs you already hold |
| Selling | Take payments | Screen every one, apply 3D Secure where it lifts approval, and retry soft declines |
| Getting paid | Pick a schedule and a rail | Pay out, then prove the deposit against the settlement file and the bank |
| When it goes wrong | Approve the evidence we assembled | File before the deadline, and surface reserves and ratio warnings early |
Timelines depend on category and how complete the application is. Your account contact will tell you what to expect for your profile.
The portal you run the business from.
Payments, payouts, disputes, and reports in one place, with the reserve and the next payout visible before you have to ask where the money is.
Sample data
Find out if you are boardable.
Tell us the category and the volume. We will say early whether it is in scope and what underwriting will ask for.
Solutions / Agents and ISOs
For agents and ISOsOne relationship that reaches several processors
Submit a lead once and follow it to a live MID. When a partner's appetite does not fit, the file moves instead of dying, so more of what you write actually boards and stays on your book.
More of what you submit actually boards.
The difference is not effort. It is that the file is built once, in a format partners accept, and it can go somewhere else when the first answer is no.
| Submitting directly | Through High Wire | |
|---|---|---|
| Where it goes | One processor at a time, each with its own form and its own evidence list | One file, submitted to the partners whose appetite fits it |
| When it is declined | Start again somewhere else, from scratch | The file moves to another partner without re-papering the merchant |
| Status | Chase an underwriter and hope | Every application's stage visible in your portal |
| Residuals | A statement you have no way to check | Calculated from the same ledger that produces the merchant's statement |
| Risk | You find out when the account is closed | Ratio, reserve, and dispute alerts on your portfolio before it gets there |
| Your merchants | Log in to somebody else's portal | Your portal, your brand, one login across every processor |
Your portfolio in one console.
Merchants, applications in flight, residuals month to date, and the accounts that need attention before they become a problem.
Sample data
Send us the deal you cannot place.
We will tell you whether we can underwrite it and which partner it would go to.
Solutions / Platforms
For platformsPayments inside your product, without becoming a payments company
Embedding payments is a question of how much of it you want to own. Building it yourself is a roadmap that never finishes. Becoming a payfac is a compliance program with staff attached. There is a third answer.
Build it, become it, or embed it.
All three get payments into your product. They differ in what you carry afterwards, which is the part that is hard to reverse.
| Build it yourself | Become a payfac | Embed High Wire | |
|---|---|---|---|
| Sub-merchant onboarding | You build the forms and the KYB | You build it and you own the decision | KYC, KYB, and boarding under your brand, underwritten by us |
| Compliance and liability | Shared with whoever you integrated | Yours, including the losses | Carried by us and the sponsor bank, with your exposure stated up front |
| Fraud and disputes | A second vendor and a second integration | A team you hire | Screening and dispute handling on every sub-merchant by default |
| Payouts and splits | You reconcile it yourself | You reconcile it yourself | Splits recorded at capture, payouts proved against the bank |
| Branding | Yours, if you build it | Yours | White-label checkout, portals, and domains |
| If a processor says no | That sub-merchant is stuck | You place them yourself | The file goes to a partner whose appetite fits |
| What you maintain | The integration, forever | The program, forever | Your product |
One console across every sub-merchant.
Boarding status, volume, and risk for the whole platform, on your own checkout domain and under your own brand.
Sample data
Put payments in your product.
Tell us how your sub-merchants sign up today, and we will show you what it looks like with boarding built in.
Company / About us
About High Wire
We sit between the businesses that need to get approved and the banks and processors that decide. We underwrite before anyone is asked, submit only where appetite fits, and stay accountable for the portfolio after it boards.
Why we built it.
High Wire started inside the problem rather than next to it. Running payments at volume, for businesses that were hard to place, meant assembling the stack yourself.
Twelve logins, ten renewal dates, and no single place where a payment’s whole life is written down.
One platform.
One merchant record.
One set of books.
Underwriting, acceptance, risk, routing, payouts, and reconciliation on the same record, across every processor you are boarded with. A change in any of them is a change in all of them.
Every one of those tools worked. None of them knew about each other. A card updated in one system did not update in the vault. A dispute won in one console never reached the ledger. When a processor changed a fee or started slowing down, nobody found out from the software. They found out from the payout.
The obvious answer was one more tool. We built the opposite. At high volume, across several processors, that is the difference between a business that runs and a business that is permanently reconciling.
Stability is not something you buy. It is what integration produces.
Where we sit in the chain.
Merchants, agents, and platforms come to us. Banks and processors decide. In between sits a platform built to run commerce that does not fit on a single processor: acceptance, risk, routing, payouts, and books that balance.
The demand side
- MerchantsDirect
- Agents and ISOsPortfolios
- PlatformsSub-merchants
- Existing MIDsConnected
We are not the acquirer. The decision stays with the partner. The preparation, the monitoring, and the reconciliation are ours.
Come and look at the file.
Partners are welcome to review how we underwrite, and what we keep monitoring afterwards, before agreeing to anything.
Company / Our mission
Our mission
To build the commerce infrastructure that makes complex businesses worth banking. A merchant who gets approved and stays approved, and an acquirer whose portfolio performs, are not two goals in tension. They are the same outcome.
Both sides of the same account.
Complex commerce is usually framed as a fight: the merchant wants a yes, the acquirer wants less exposure. Read the two columns across and they ask for the same things in different words. Everything we build lives in that overlap.
| What has to work | The merchant needs | The acquirer needs |
|---|---|---|
| Getting approved | A yes that holds, from a partner who understood the business | A file complete enough to decide on, in the same shape every time |
| Staying approved | No account closed without warning three months in | No account that quietly goes bad after it boards |
| Fraud | Losses stopped without blocking real customers | Ratios kept under the network program thresholds |
| Disputes | Evidence filed on time, cases actually won | Fewer cases escalating, less exposure carried |
| Reserves | Knowing what is held, why, and when it releases | Exposure covered without renegotiating every quarter |
| The money | Payouts that arrive when they are supposed to | Settlement that balances against the ledger every day |
This is the whole thesis. A platform that only serves one column produces accounts that do not last.
What we believe.
Most declines happen because an application arrives incomplete. Doing the verification properly, up front, changes the answer for a lot of good businesses.
A business that can only accept payments one way is one risk decision away from having no revenue at all. Spreading that risk is worth as much to the partner carrying it as to the merchant.
Every statement should trace back to an event, and every day should balance against an outside source. Finance teams should not have to take our word for it.
Good underwriting and monitoring serve the merchant, the agent, and the partner bank at the same time. It is not a tax on growth.
Agents can decide, route, and prepare evidence, but a person stays responsible for anything significant.
If a category is out of scope or a reserve will be required, a merchant should hear it before integrating, not after.
Beliefs are drafted. Replace with the founders' own words before launch.
Hold us to it.
If the platform stops working for either column, we would rather hear it from you than read it in a statement.
High Wire Lift
Products / Optimize
High Wire LiftThe acceptance suite: tokens, updater, retries, and cascading
Most lost revenue is not fraud. It is good payments that fail: an expired card on a subscription, an issuer that says no for a reason that would not apply a minute later, or a processor having a bad hour. This is the set of tools that recovers them.
Six tools working on the same payment.
Each one helps on its own. Together they decide whether a payment that should succeed actually does.
A credential issued by the card network in place of the card number. When the customer's card is replaced, it keeps working, so stored cards and subscriptions do not break. The card number is kept as a fallback and retried when a token attempt fails. Whether the token travels with you depends on who requested it, which is covered below.
Around four in ten cards are replaced each year after expiry, loss, or fraud, and most customers never update the businesses storing them. We refresh those details automatically instead of waiting for the decline.
Retries driven by the decline code and the issuer's behavior, not a fixed schedule. A soft decline is retried differently from a "do not honor," and retries stop when they are only adding cost.
When one processor declines or stops responding, the payment is re-sent to another MID that can take it, including one you own. The customer sees one attempt.
Every retry costs money and can attract network scrutiny. We cap attempts per card, per issuer, and per window, and report what the retries actually earned.
Different processors perform differently with the same issuer, BIN range, and market. Routing follows the evidence and updates as the evidence changes.
High Wire Vault
Where your stored cards actually live.
A stored card base living inside one processor's vault is the quietest form of lock-in in payments. Moving it later is a regulated-data migration with a coordinated cutover, which is why few businesses ever do it, and why processors stay relaxed about your pricing conversations.
High Wire keeps the vault, so your stored cards are held independently of any one processor. How freely a given credential moves depends on who requested it, and we tell you which of your processors share network tokens and which keep their own reference behind one. Where a processor abstracts the credential, moving that volume is a card data migration, and we run it rather than leave you to negotiate it.
| Credential type | Who requested it | Can it be charged on another processor? |
|---|---|---|
| Processor reference | The processor, under its own credentialsCommon. You receive an identifier that only that processor understands | No. Moving means a card data migration between PCI-compliant providers, which we run for you |
| Network token requested by a processor | The processor, under its own token requestor ID | Not in practice. Lifecycle updates and cryptograms still come through that processor |
| Network token requested independently | A token requestor ID that is not tied to one processorWhere we are heading: tokenizing the card before the payment reaches any processor | Yes. The same credential can be presented to whichever processor you route to |
| PCI scope | Reduced, and tied to that processor | Reduced, and not tied to one processor |
Roadmap: requesting network tokens ourselves, so a card is tokenized before the payment reaches any processor and the same credential can be routed to any of them. Until that is live, portability is per processor, and we tell you which is which before you board.
What happens to a declined payment.
Not every decline should be retried, and the ones that should are not all retried the same way. The ladder below is what runs before a customer ever sees a failure.
Sample flow. Attempt caps and retry windows are configurable per merchant.
Subscriptions lose customers to expired cards, not cancellations.
Involuntary churn is the quietest revenue leak in recurring businesses. Updated credentials, network tokens, and retry timing tuned to the billing cycle keep customers who never intended to leave.
Prove it, then tune it.
Every claim on this page should be visible in your own data, by processor, market, card type, and issuer. Routing changes can be split-tested before they are applied to all traffic.
Compare processors on the same traffic, with the difference expressed in approved volume rather than percentage points alone.
Send a share of traffic down an alternative route, measure, then promote the winner. No code change, and no waiting on an engineering cycle.
What retries recovered, what they cost, and which decline codes are worth pursuing for your book.
Lift approvals on the traffic you already have.
Most of the gain is in payments you are already sending. Start by measuring where they fail.
High Wire Margin
Products / Optimize
High Wire MarginInterchange, surcharging, and the cost of accepting a card
Two merchants with identical volume can pay very different effective rates. The difference is card mix, the data sent with each authorization, how payments are routed, and who carries the fee. All four are things you can change.
Where the money actually goes.
A processing rate is three separate charges bundled into one number. Knowing which is which tells you what is negotiable, what is fixed, and what we can move on your behalf.
| Component | Paid to | Can it move? |
|---|---|---|
| Interchange | The cardholder's issuing bankThe largest share of the cost | Yes, indirectly. Card mix, Level 2 and 3 data, entry method, and settlement timing decide which rate applies |
| Assessments and scheme fees | Visa, Mastercard, and the other networksA small percentage plus per-item fees | Barely. These are set by the networks and are the same for everyone, though cross-border, token, and authorization fees vary |
| Processor and platform markup | Your processor, and High WireWhatever was negotiated | Yes. This is what pricing conversations are actually about, and the part a blended rate hides |
Interchange plus shows all three separately. A blended rate shows one number, which is usually why it is higher.
Send more data, pay less interchange.
Commercial, corporate, and purchasing cards qualify for lower interchange when the authorization carries more detail about the purchase. Most gateways accept the fields and never ask merchants to fill them in, so the saving is quietly left on the table.
| Data level | What is sent | Where it helps |
|---|---|---|
| Level 1 | Card number, amount, dateThe default for most transactions | Consumer cards, where no further data is required |
| Level 2 | Tax amount, customer reference or purchase order number, merchant tax ID | Business and corporate cards, typically a lower interchange tier |
| Level 3 | Line item detail: description, quantity, unit of measure, unit price, commodity code, freight and duty | Purchasing and government cards on larger B2B tickets, the largest saving of the three |
Sending the data is not enough to qualify.
These rates apply only to commercial, corporate, purchasing, and government cards. A consumer card gains nothing from the extra fields. Every required field has to be present and valid, and the transaction has to settle inside the network's window. Miss one and it downgrades quietly, which is why most merchants never notice.
We validate the fields before authorization and report which transactions qualified, which downgraded, and why.
What this looks like on real volume.
Move the inputs to see how card mix and data levels change what you pay. The arithmetic is deliberately simple and uses your numbers, not ours.
Illustrative. Real interchange differs by card product, merchant category, ticket size, and region, which is why we read your statements rather than estimate.
Who carries the fee.
Passing card costs to the customer is legal in most of the United States, banned in a few places, and tightly governed by network rules everywhere. Done wrong it brings fines and, for repeat breaches, account termination. Done properly it changes the economics of a low-margin business. There are three compliant models, and the right one depends on where you trade.
A fee added to credit card payments only, never to debit or prepaid, capped at the lower of your actual cost of acceptance or the network ceiling. Requires advance notice to your acquirer and the networks, and is prohibited in a small number of states.
Two posted prices, one for card and one for cash, shown before the customer chooses. Permitted nationwide, including in states that ban surcharging, and it tends to test better because the customer sees the price they will pay.
The card price is your posted price, and customers paying cash get a discount. Permitted in all fifty states, including the surcharge-ban states, because it rewards cash rather than penalising cards.
What compliance actually requires.
These are the rules that get merchants fined. We enforce them in the checkout and on the receipt rather than leaving them to be remembered.
| Requirement | The rule | How High Wire handles it |
|---|---|---|
| Never surcharge debit | Debit and prepaid cards cannot be surcharged anywhere, including debit run as credit without a PINThis one carries the heaviest consequences, up to account termination | Card type is detected at authorization and the surcharge is removed automatically. It is not a setting a merchant can get wrong |
| Stay under the ceiling | The lower of your actual cost of acceptance or the network cap. Visa's cap has been 3% since April 2023 and Mastercard's is 4%, so 3% is the practical limit for merchants taking both | A cap per merchant, enforced at checkout, with the rate checked against that merchant's real cost of acceptance |
| Respect state rules | A small number of states prohibit surcharging outright, and others cap it below the network ceiling, for example 2% in Colorado and Oklahoma. New York governs how the price must be displayedBan lists change and sources disagree. Counsel confirms the list we enforce | Rules are held per state and applied by the merchant's location, with cash discount or dual pricing offered where surcharging is not permitted |
| Give advance notice | At least thirty days' notice to your acquirer and the card networks before surcharging begins | We file the notice as part of boarding, and the start date is held until it clears |
| Disclose it properly | Clear notice at the entrance and the register in person, on the checkout page before card details are entered online, and as a separate line item on the receipt | Disclosure text and the receipt line item are part of the checkout, not a merchant to-do |
Jurisdiction rules summarised for review, not legal advice. The enforced list is confirmed by counsel before launch.
Debit deserves its own answer.
Debit cannot be surcharged, but it can be routed. In the United States most debit cards carry more than one network, and the cheaper route is not always the one the card would pick by default. On card-present volume with small tickets, this is often the largest saving available.
The same logic applies online for merchants whose customers pay by debit: route to the network with the better economics for that transaction, then show the difference in the ledger.
The other levers.
Interchange is only part of the bill. Routing, retries, tokens, and fee accuracy each move the effective rate, and all of them are visible in the ledger rather than in a processor's summary.
Questions merchants ask about cost.
What is a good effective rate?
There is no universal answer, because card mix decides most of it. A business taking mostly consumer debit on small tickets and a supplier taking purchasing cards on large invoices should expect very different numbers. The useful comparison is your rate against your own card mix, which is what a statement review produces.
Is interchange plus always cheaper than blended?
Not automatically, but it is always clearer. A blended rate averages your cost and keeps the difference when your mix is favourable. Interchange plus shows interchange, scheme fees, and markup separately, so a price increase is visible rather than absorbed.
Will Level 2 and 3 data help my business?
Only if commercial, corporate, purchasing, or government cards are a meaningful share of your volume. If you sell to consumers, the extra fields change nothing. If you sell to businesses or government buyers, it is usually the largest single saving available.
Can I surcharge everywhere?
No. A small number of states prohibit it, several cap it below the network ceiling, and debit can never be surcharged anywhere. Where surcharging is not available, cash discount and dual pricing are, and we apply the right model for the state you trade in.
Does surcharging cost me customers?
Sometimes, and it depends on your category and your competitors. Dual pricing tends to test better than a fee added at the end, because the customer sees the price they will pay before they choose. We would rather model that trade-off with you than sell you a percentage.
What if my processor has been overcharging me?
Fee variance checking compares expected interchange against what was actually billed, per transaction. Where there is a gap it becomes an exception on the Ledger with evidence attached, and we pursue the recovery.
Find out what you are actually paying.
Send three months of processing statements. We return your effective rate by card type, the share of commercial volume that is downgrading and why, any fee variance we can see, and what surcharging or dual pricing would mean in the states you trade in. Usually within five business days, and there is no charge for it.
High Wire Board
Solutions / Industries
IndustriesWhat we underwrite, and what each category has to show
Processors decline by category first and look at the business second. We work the other way around: what the business actually sells, how it sells it, and what its history looks like.
Categories we work with.
Each one carries different chargeback behavior, different network scrutiny, and different partner appetite. Underwriting asks for different evidence accordingly.
| Category | What underwriting looks at | Typical terms |
|---|---|---|
| Supplements and nutraceuticals | Claims made on the site, subscription and trial terms, refund policy, fulfilment evidence | Rolling reserve, chargeback ratio monitoring |
| Subscriptions and memberships | Trial-to-paid conversion, cancellation flow, dunning behavior, involuntary churn | Standard terms, retry and updater strongly advised |
| Coaching and online education | Delivery timeline, refund windows, claims about outcomes, affiliate marketing | Reserve depends on delivery lag |
| Telehealth and wellness | Licensing, prescribing model, state coverage, pharmacy relationships | Compliance review before boarding |
| Travel and events | Time between payment and delivery, cancellation exposure, supplier risk | Reserve sized to delivery lag |
| Software and SaaS | Billing model, free trials, card testing exposure on signup | Standard terms, fraud rules on signup flows |
| Retail and wholesale | Fulfilment times, dropshipping, average ticket, seasonality | Standard terms, Level 2 and 3 data for B2B |
| Marketplaces and platforms | Seller onboarding, payout obligations, liability split | Sub-merchant onboarding and split payouts |
Sample categories. Confirm the real list, plus categories that are out of scope, before publishing.
Hard to place is not the same as high risk.
Plenty of good businesses get declined for the category on their application rather than anything they have done. Where the risk is real, we would rather price it, reserve for it, and monitor it than pretend it is not there.
If a category is genuinely out of scope for us and our partners, you will hear that in the first conversation rather than after an integration.
Tell us the category.
We will say early whether it is in scope, what underwriting will ask for, and whether a reserve is likely.
Company / Security and trust
Security and trustHow card data, merchant data, and money are protected
Payments buyers ask three questions: where does card data live, who can touch our account, and what happens when something breaks. These are the answers.
Certifications and audits.
What an auditor has actually looked at, and what a partner or enterprise buyer can ask us for. Everything marked below needs a date, a scope, and a name before it is published.
The certification every merchant, partner, and acquirer asks for first. Publish the level, the scope of the assessment, the assessor, and the date of the most recent attestation of compliance.
Controls tested over a period rather than on one day, covering security and availability. Report period, auditor, and the trust service criteria in scope. Shared under NDA.
The one people forget. Because we reconcile settlement, hold reserves, and produce statements, we sit inside our customers' financial reporting. Auditors of larger merchants and bank partners will ask for this specifically.
Quarterly external scans by an approved scanning vendor, internal scanning, and a stated remediation window by severity. This is a PCI requirement, not an optional extra.
Cadence, whether it covers the API, the portals, and the network, whether it is tested after significant change, and whether an executive summary can be shared.
Cyber liability and errors and omissions cover, with limits. Bank partners and enterprise procurement ask for certificates before they ask about architecture.
Compliance programs.
Underwriting merchants and moving money brings obligations that outlast any single audit.
Screening of businesses and beneficial owners at onboarding and continuously afterwards, escalation and case handling, and record retention that meets financial record-keeping rules. Partners will want the program described, not just claimed.
Background checks before access is granted, security training on joining and annually, and access removed the day someone leaves. Most incidents start here rather than in the code.
How providers who touch merchant or cardholder data are assessed before onboarding and reviewed afterwards, and where the published sub-processor list lives.
How card and merchant data is handled.
Practices rather than certificates, and the questions that come up in every security review.
Card details are tokenized on capture and held in the High Wire vault. Some processors share network tokens with us and some return their own reference instead, so we tell each merchant which applies to their processors. We are moving toward requesting network tokens ourselves, before a payment reaches any processor.
High Wire Checkout and Components keep card data off your servers. API checkout means card data passes through you, which changes which self-assessment questionnaire applies to your business. We will tell you which one before you build.
Encryption in transit and at rest, where keys live, who can reach them, and how often they rotate. Publish the standards rather than the word "encrypted".
Which providers process and store merchant and cardholder data, and what can be pinned to a region on request.
Scoped keys with separate sandbox and live credentials, key rotation without downtime, signed webhooks with replay protection, and rate limiting. The things an engineer checks before writing any code.
Which data AI agents can reach, what is logged for every decision, what requires human approval, and whether customer data is ever used to train models. Increasingly the first question enterprise reviewers ask.
What we keep, and for how long.
Payments records cannot simply be deleted on request. Anti-money-laundering and financial record-keeping rules require onboarding files, verification results, and transaction history to be retained for years after an account closes, and those obligations override a deletion request.
Cardholder data is processed on behalf of merchants, so requests from a cardholder come through the merchant under the agreement rather than directly to us. Merchants can export their own data at any time, and we say plainly what stays behind afterwards.
Access, availability, and what happens when something breaks.
Most security incidents in payments are not exotic. They are an old employee account, a shared password, or a webhook nobody was watching. The controls below are aimed at exactly that.
Ask us the hard questions.
Security reviews, questionnaires, and sub-processor lists are answered by the team that runs the platform.