◆ Railspan module
Proposed offeringPart of Railspan, the modular payments and banking platform. This page details the module scope within that offering.
Subscription Billing Operations
Give billing teams a traceable path from subscription change to invoice and payment outcome.
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
Plan changes, payment attempts and invoice questions cross several systems. A team can bill successfully yet still struggle to explain a balance or diagnose why a collection failed.
Build a customer-specific operations experience around subscription, invoice and payment services. Begin with one catalog and one processor, then validate the financial behavior before adding usage-based pricing or more channels.
Designed for
A subscription or platform business with complex plan changes, collections operations and enough integration need to justify a dedicated implementation.
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.
Compare plan, effective date and entitlement impact.
Inspect the illustrative adjustment before issuing anything.
Separate a confirmed decline from an unknown provider outcome.
Assign investigation or an approved, idempotent collection action.
A declined attempt remains visible with its invoice context and owner. No invoice or collection is issued by this page.
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.
Tax calculation, local invoice compliance, accounting treatment and usage metering are not inferred from subscription APIs. Lago is a separate engine option when metering is central, not a mandatory extra service.
Business use cases
Follow a planned change through the effective date, generated invoice and payment attempt.
Group a failed attempt with provider evidence and choose an allowed next action.
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. |
| Stripe Billing ↗ | A hosted billing service when its catalog, collection and integration model fit. | Observed 0.7% of Billing volume on the Netherlands pricing page. | The rate is separate from payment processing. Tax, invoice rules and usage-billing scope need their own comparison. |
| Chargebee ↗ | Subscription teams evaluating a managed catalog and billing operations package. | Flow displayed $0 + 0.80% or $99 + 0.65% against monthly invoicing volume. | Confirm market, currency, calculator inputs and add-ons before a like-for-like quote. |
| Lago ↗ | A separate engine option when usage metering and events are central. | Premium Cloud and self-hosted packages: contact sales; no numeric quote verified. | Premium extensions, branding, tax and support can require additional terms; Lago is not a mandatory extra layer. |
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
Not necessarily. Dedicated engineering and operations can exceed SaaS fees. Compare the same workload, required integrations and support commitments.
That requires a separate metering scope and may use an alternative engine. Event idempotency, adjustments and backfills must be tested.
No such replacement is included. Define the tax and ledger integrations and reconcile outputs before migration.
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.