Use Case: Fintech

Add invoicing to money movement, not beside it

For fintechs, the value is not just issuing invoices. It is linking documents to payment events, keeping reconciliation sane, and giving business customers a compliant document layer inside the same product. The expensive part is not the PDF. It is the workflow correctness around payment state, reversals, and cross-border rules.

Start free sandbox View fintech docs

Who This Is For

You already handle payment, banking, or treasury events for business customers

You need invoices and payment reconciliation in the same product flow

Each business customer should stay isolated with its own invoicing identity

Not A Fit

You only need subscription billing logic

You do not want backend event handling in your product

You have not modeled a business identity for customers yet

Common Underestimation

Teams underestimate reconciliation-linked document workflows

It is easy to issue a document after a payment succeeds. It is harder to keep invoice state, payment state, reversals, and compliance behavior aligned over time.

Recommended Path

Use your event layer as the integration backbone

Most fintech teams should use an account key and the JavaScript SDK on the backend. That lets you create entities for business customers, issue invoices from payment events, and reconcile status without losing control of the product flow or document lifecycle.

Event-driven creation

Use payment or account events as your trigger surface.

Reconciliation first

Keep invoice IDs and payment IDs linked from day one.

Entity Model

One business customer = one entity

Keep payment rails, balances, and ledgers in your fintech stack. Use Space Invoices as the document and compliance layer attached to each business customer.

Business identity Per entity

Payment linking Metadata + IDs

Access Optional later

First Sandbox Milestone

Prove one event-driven invoice flow

Before shipping UI, validate that one payment or account event can create the right document, render it, and survive one reversal or failed-payment scenario.

Create one sandbox entity for a business customer

Trigger invoice creation from a payment or account event

Render the invoice and verify document details

Record or reconcile payment status and test one reversal case

Operational Gotchas

Do not couple payment success and final document issuance until business rules are clear

Store external payment IDs in metadata for reconciliation and support

Use credit notes for reversals rather than rewriting finalized invoices

Compliance Notes

Business customer country drives much of the compliance behavior, but cross-border issuance can still change tax treatment even when the payment is domestic.

Sandbox should validate both document creation and payment-linking assumptions before you expose invoice status in customer-facing product surfaces.

See webhook patterns See reversal flows

Start with one workflow, not a whole rewrite

Free sandbox with no time limit. Prove one entity and one invoice flow before deciding how much UI, compliance, and rollout surface you want to own.

Start free sandbox See platform architecture