◆ Railspan module
Proposed offeringPart of Railspan, the modular payments and banking platform. This page details the module scope within that offering.
Payment Operations Control Workspace
Make provider routing and payment-state investigation visible in a defined operating boundary.
Concept-stage implementation service. The foundation has been reviewed in source; this RZIFI offering has not been delivered or deployed for a customer.
The operating problem
A payment can pass through several providers, callbacks and internal records. Routing controls are only useful if the team can understand the outcome and recover safely when records disagree.
Use a payment orchestration foundation for a bounded provider scope. Add an operator workspace, an agreed status model and reconciliation evidence. Validate one processor path before introducing automatic routing decisions or additional money movement.
Designed for
An established PSP or platform with processor contracts, authorized technical access and a clear operational owner.
Explore the workflow
Illustrative workflow with synthetic data. This is a static product concept, with proposed integration and control behavior to validate during a pilot.
Read the selected rule, attempt ID and connector reference.
A timeout remains unknown rather than automatically failed.
Retrieve provider evidence and correlate callback state.
Permit a change or retry only after reconciliation and approval.
Unknown outcomes remain in investigation. This page initiates no payment, payout, routing change or settlement.
Capabilities and scope
Source review identifies building blocks. Integration, configuration and deployment acceptance still determine what the customer implementation can do.
Implementation found in upstream source. No runtime or production claim follows from this review.
New work to design, integrate and test against your requirements.
Roles, report access and data boundaries are mapped to the customer operating model. Shared multi-customer administration and enterprise identity require explicit scope.
A switch is not an acquiring license, bank account, settlement service or universal provider connector. Payout, treasury, ledger and stablecoin capabilities must be specified separately. Source presence does not prove a live provider integration.
Business use cases
Trace a synthetic attempt through the chosen connector and separate provider decline from an unknown timeout.
Compare a proposed routing rule with a test case, record approval and preserve rollback context.
Compare approaches
An existing SaaS package may be the better choice for standard needs. Compare the same workflow, workload, geography, data boundary and support commitment. No savings or performance advantage is assumed.
| Approach | When to consider it | Observed commercial basis | What needs checking |
|---|---|---|---|
| RZIFI proposalProposed offering | A specific workflow, integration or deployment requirement justifies dedicated engineering. | Scoped discovery and implementation, with optional recurring operations. Request a quote. | Selected license, tenant boundaries, integration acceptance, operating ownership and total cost. |
| Spreedly ↗ | Teams evaluating vaulting and payment optimization services. | Independent Vault starts at $750/month; optimization requires a sales discussion. | A vault starting price is not a complete orchestration price. Routing, retries and fraud require package-level scope. |
| Primer ↗ | Teams evaluating managed orchestration and operational intelligence. | No verified numeric public price; enquiry. | Compare processor coverage, workflow, data access and operating support; no own-brand source rights were established. |
| Yuno ↗ | Businesses evaluating routing, payment connectors and related operations. | No verified numeric public price; enquiry. | Vendor integration or performance claims do not transfer to a proposed RZIFI implementation. |
Deployment and customization
A dedicated customer environment is the preferred first design target. Managed hosting, customer cloud and on-premises delivery each require their own validated package and operating agreement.
Commercial scope
Request a scoped quote. Paid discovery defines the workflow and acceptance criteria, followed by a separate implementation scope and an optional operations agreement. Licenses, infrastructure, model/API usage, payment processing, taxes and unusual migration work are identified separately.
One workflow and agreed test data. Define the acceptance cases and limitations before implementation.
Validate the selected integrations, authorization, recovery, upgrades and operating handover. Release follows observed acceptance.
Scope buyer-specific identity, audit, regional deployment, recovery and support commitments. Certification is a separate requirement.
These are potential delivery scopes, not existing service tiers or committed calendar dates. Discovery is part of the agreed delivery scope; any separate discovery invoice is accounted for in the implementation quote.
Purchasing questions
No. Each connector, payment method, region and operation must be checked against implementation and the provider contract, then tested.
No. It can mean the outcome is unknown. Reconcile against provider evidence before a retry to avoid duplicate movement.
Not in the initial scope. Those require separate balance, settlement, custody and operational controls; TigerBeetle alone is a ledger component, not the whole product.
Discovery identifies the workflow, data boundary, selected edition, integrations and acceptance criteria. Implementation and optional ongoing operations are quoted against that scope. There is no standard package or committed list price at this concept stage.
A dedicated customer environment is the first design target. Customer cloud, managed hosting and on-premises options are evaluated separately against the chosen foundation, identity requirements and operating owner. A tested deployment and recovery procedure are required before a commitment.
The agreed scope should name authorization and integration tests, data migration checks, backup and restore, upgrades, vulnerability handling and operating responsibility. Certifications, regulatory approvals, service levels and performance outcomes are not implied by a proposed offering.
Start with your operating problem
Discuss the requirements, the foundation and the work needed before a launch. The next step is a scoped conversation.