Collect
Stand up accept without rebuilding checkout. Merchant API and hosted patterns, scoped to what you actually need first.
3
core surfaces — collect, connect, settle
2
product paths — gateway or introduced direct
5
steps from brief to production handoff
1
honest scope per deployment
Product
What you get — without the fog
The pieces operators and merchants actually run: accept cleanly, stay in the loop on status, settle without the mystery inbox. Admin and merchant dashboards ship with analytics — custom communication if the brief needs it.
Connect
Wire providers once. Webhooks push money events into your stack — status you can operate, not a mystery inbox.
Settle
Settlement shaped for operating teams. Rails and timing stay honest to the deployment you briefed, not a catalog page.
Admin and merchant dashboards
Both are available. Analytics on the operating picture come with the surface. Custom communication can be added when you need it — notices, status, and the messages you actually send — not a generic campaign bolt-on.
Admin dashboard
The operator surface. Analytics on accept, status, and settle — so the day is visible without reconstructing it from inboxes.
Merchant dashboard
Merchants get their own view of activity. Same lifecycle, scoped to their store — not a copy of the admin console.
Integration styles
Simple
Hosted patterns and clear status when you need to ship first. Deepen the stack when the operation is ready.
Technical
API-first, webhook-native, ops-friendly events — for platforms that already ship for real and want the lifecycle in their own tools.
Engagement model
Two paths — same Altrevs system
Altrevs is a developer and merchant gateway. You can run money through our gateway, or we can introduce a provider for a direct merchant connection — while Altrevs still owns the system relationship and visibility.
Path 1
Through the Altrevs gateway
Collect, connect, and settle via us. Accept → status → settle stays on the Altrevs surface — a gateway hop in the payment path, ops clarity in one place.
- Merchant and developer traffic through Altrevs
- Status and settlement shaped for how you operate
- Rails and providers scoped per deployment
Path 2
Direct provider ↔ merchant
We introduce a payment gateway provider to integrate directly with the merchant. That integration can skip the Altrevs gateway hop — Altrevs still orchestrates the introduction and retains system visibility and ownership of the relationship.
- Altrevs-orchestrated introduction — not a cold handoff
- Direct connect where it fits the merchant’s stack
- Relationship and visibility stay with Altrevs
Payment path
Merchant
Checkout & API
Altrevs gateway
Accept · status · settle
Provider rails
Scoped per deploy
Money events and settlement stay on the Altrevs surface so operators are not reconciling a black box.
Live provider names, fees, and coverage are scoped in briefing — we don’t list inventable “any provider” claims on this page.
Platform
How the system fits together
Platform-style view of the stack. Rails are generic here — live coverage is scoped per deployment.
01
Accept → status → settle
One lifecycle operators can brief against — from checkout intent to clearing handoff.
02
Gateway or introduced direct
Either through Altrevs, or Altrevs-introduced provider ↔ merchant. The system relationship stays ours.
03
Build · Connect · Settle
An operating model you can staff: configure, integrate, then settle with eyes open.
- 01Intent
- 02Authorize
- 03Capture
- 04Status
- 05Settle
Merchant
Hosted checkout or API. Intent lands with a status you can subscribe to.
Altrevs gateway
Orchestration, events, and dashboards — or the introduction if the hop is skipped. Analytics ship with the surface; custom communication when the brief needs it.
Provider rails
Named in briefing. Not a public partner wall of logos we cannot stand behind.
Engagement
How we start — without the fog
Five steps from brief through sandbox UAT to the production handoff. Honest scope per deployment.
Step 1 of 5
Brief
Who you serve, what volumes look like, which flows matter first.
BriefScopeBuild / configureUAT in sandboxHandoff to production
- Step 1
Brief
Who you serve, what volumes look like, which flows matter first.
- Step 2
Scope
Lock MVP versus roadmap before anyone writes a line.
- Step 3
Build / configure
Gateway surface, monitoring, handoff — configured to your scope.
- Step 4
UAT in sandbox
Prove the scoped flows in sandbox. Operators and merchants sign off before anything hits live rails.
- Step 5
Handoff to production
Sandbox sign-off becomes the cutover: gates, owners, and the first live settlements. Altrevs hands off into production with you — not over you.
FAQ
Straight answers
The questions operators actually ask before a briefing.
Next step
Let’s talk
Operator or merchant use case — volumes, flows, timeline. We’ll follow up on pilot fit. Sending a message opens your email client with the briefing addressed for us.