No. Settlerock is the layer above the PSPs and acquirers. You integrate once with us; we route each payment to the rail most likely to approve it, rescue gateway refusals in the same call, and hand you one settlement file.

Acquiring, processing and the safeguarding of funds sit with licensed partners named in your agreement.

Merchants the mainstream PSPs decline or derisk: iGaming, forex and CFD, digital assets, health and nutra, dating and entertainment, fintechs and the complex verticals nobody has a category for yet.

If your business is legal where you sell, licensed where required and honestly described, we can usually find a rail.

Not on the website. Rates, reserves and settlement schedules depend on your vertical, your history and the rail we underwrite you onto. They are quoted per merchant and written into the agreement before you process a cent.

Anyone quoting you numbers before reading your business is guessing.

Naming them tells your competitor where you process and invites every merchant we turned down to knock on their door. Rails carry a stable label for the life of your account, and the provider reference you reconcile against never changes.

It means a feature exists and runs for design partners but is not yet available to every account, usually because a partner contract is still landing. We never write "coming soon". The honest scope page lists what is live, planned and never.

Eligibility is static: scope, currency, country, scheme, entitlement and the compliance layer decide which terminals may see a payment. Among the survivors, the observed approval rate for that payment’s segment decides who goes first.

The score is (approved + 2) / (attempts + 4) over seven days, with the last 24 hours counted twice. Not a model. Not a mystery.

When a gateway refuses a card before any issuer saw it (a country rule, a BIN block, a terminal policy), the payment hops to the next eligible terminal inside the same request. Depth cap two. Issuer declines and fraud verdicts are never retried.

Yes. Rules are an override layer: pin a scheme to a terminal, block a country, cap a share. The router still learns underneath, so when you remove a rule it knows where to go.

Fewer than 15 attempts in a segment and the score falls back to the terminal’s zone, then to the terminal overall. Ten percent of traffic explores, so a cold terminal earns its share back instead of being starved.

Which terminals were eligible, the scores it used, the policy, whether the payment explored, every hop with its outcome and latency, and a link to the Explain panel. It is on every payment, in the API and in the dashboard.

T+1 by default where the partner rail supports it, with no minimums. Instant payouts arrive later as a paid feature, and we will not quietly rebrand fast-ish as instant.

The licensed partner carrying the rail. The dashboard labels every balance with its custodian, and every payout can only go to the destination verified at onboarding.

USDC and EURC to your wallet, executed by a licensed partner at a contracted quote, per payout destination. It carries an early-access label until your partner contract lands. USDT is blocked for EEA users by a compliance layer merchant config cannot override.

Rolling reserves are stated per risk tier at underwriting and written into your agreement. The dashboard shows the release schedule to the day. Nothing moves that is not in writing.

A dispute references its payment and its financial impact lands as ledger entries, never annotations. Early alerts you refund in time never count against your ratio.

Sandbox is instant. Live mode requires business verification: every business is reviewed by a person before live keys exist. Bring the evidence for your category and the first email can be the last.

Termination history is underwriting input, not a disqualifier. Hiding it is what costs everyone a month.

Unlicensed gambling, weapons, illegal drugs, prescription pharmaceuticals, counterfeits, pyramid schemes, binary options and a few more. The full list is on the restricted businesses page, rendered from the same data our review tooling uses.

No. The Copilot proposes; a person confirms. Playbooks are bounded to traffic shares, pauses, policies, refunds of early alerts, drafts and notifications. No automation can create a payout or change a destination.

REST, JSON, cursor pagination, expandable objects, idempotency keys on every money-moving call, typed errors with a request_log_url. Stripe-shaped on purpose, so your team already knows it.

No. Card inputs are the provider’s hosted fields or a full redirect, so your integration stays SAQ A eligible. Merchants with a current PCI DSS attestation may use the direct API, where card data is transmit-only.

Signed with rotating secrets and a 30-day dual-signature grace window, sent from a transactional outbox written inside the money-moving transaction. Per-endpoint delivery logs with one-click retry.

Yes. Test cards cover approvals, declines, 3DS challenges, async failures, disputes and gateway refusals, plus magic amounts for the failure modes that only show up in production at 2am.