Stripe Billing

A use case for engineering teams already running Stripe Billing on their own Stripe account who want to move payment collection and money movement onto Outpost as Merchant of Record — without changing the way their subscriptions, invoices, or pricing live in Stripe.

Outpost holds the saved payment method on its own PSP account, charges it for every renewal cycle, and reports the result back to you.

You keep your existing Subscription / Invoice objects and use Stripe's native PaymentRecords API to mark invoices paid by an external processor.

Your Stripe account and Outpost’s PSP account are completely independent.

What you own vs. what Outpost owns

Supported payment methods

Any Stripe payment method that supports off-session reuse with a SetupIntent works with this architecture.

Your integration code stays the same regardless of the underlying method — only the payment_method_types you pass to POST /api/payments/stripe/setup-intents changes.

Architecture

Two independent Stripe accounts plus parallel webhook delivery from your account to Outpost.

On your side the integration is a handful of well-defined pieces:

• One signup-time backend call to Outpost, picking the variant per plan: POST /api/payments/stripe/payment-intents for immediate-payment signups, or POST /api/payments/stripe/setup-intents for free-trial signups (card is saved, no charge yet).
• Frontend integration with Stripe Payment Element using Outpost's publishable key. The browser’s stripe.confirmPayment() (or confirmSetup()) is the atomic source of truth — Outpost is informed of the outcome via its own payment_intent.succeeded / setup_intent.succeeded webhook, no extra Outpost API call needed.
• Subscription bootstrap on your own Stripe account with collection_method=send_invoice, followed by payment_records/report_payment + attach_payment to mark the first invoice paid.
• Parallel webhook delivery from your Stripe account so Outpost receives invoice.created events for renewals.
• An HTTPS webhook endpoint on your backend that verifies the Mor-Signature HMAC and reacts to payment.* renewal events.

Signup — immediate payment

Signup — free trial

Renewal flow

Integration flow

Three discrete phases: a one-off signup that puts a card on file with Outpost (Phase 1), your own subscription bootstrap (Phase 2), and a renewal cycle that repeats for the life of the subscription (Phase 3).

Phase 1 — Signup

Goal: a saved payment method sits in Outpost's Stripe account, attached to a MoR-side Customer, and is ready to be charged off-session for future renewals.

Phase 2 — Subscription + report payment

Phase 2 happens entirely on your Stripe account.

No Outpost call is involved.

Use collection_method=send_invoice so Stripe Billing doesn't try to auto-charge — payment comes from the PaymentRecord you report below.

Phase 3 — Renewal cycle

Renewals are driven by parallel webhook delivery: configure your Stripe account to forward webhook events to two destinations — yours (for your own logs) and Outpost's.

Outpost reacts to invoice.created and drives the renewal charge end-to-end.

Stripe API fields

The non-default Stripe fields that make the integration work.

Everything else on the Subscription, Invoice, and PaymentRecord can stay at the defaults you already use today.

API reference

Three outbound endpoints covering the payment lifecycle (provision a SetupIntent, confirm the payment, refund), plus four inbound webhook events on a single channel.

Authentication uses the same Bearer token described in Merchant of Record → Authentication.

{
  "amount": 1990,
  "currency": "BRL",
  "merchant_customer": {
    "stripe_id": "cus_QmerchantSide",
    "email": "jordi@example.com.br",
    "name": "Jordi Silva",
    "country": "BR",
    "address": { "line1": "Av. Paulista 1234", "city": "São Paulo" }
  },
  "description": "Pro Monthly subscription — first payment",
  "tax_calculation_id": "taxc_a1b2c3d4e5f6789"
}

{
  "client_secret": "pi_3QzABC_secret_xyzXYZ123",
  "payment_intent_id": "pi_3QzABC",
  "mor_customer_id": "cus_a1b2c3d4e5f6789",
  "status": "requires_payment_method"
}

After stripe.confirmPayment() succeeds in the browser, you receive payment_intent.id and latest_charge (Stripe ch_…). Use that ch_… as processor_details.custom.payment_reference on payment_records/report_payment on your Stripe account.

{
  "amount": 990,
  "reason": "requested_by_customer",
  "metadata": {
    "merchant_invoice_id": "in_1QzABC"
  }
}

{
  "id": "rfnd_a1b2c3d4e5f6789",
  "payment_id": "pay_a1b2c3d4e5f6789",
  "amount": 990,
  "currency": "BRL",
  "status": "succeeded",
  "reason": "requested_by_customer",
  "processor_references": {
    "refund_id": "re_3QzABC..."
  },
  "created_at": "2026-05-12T11:00:00Z"
}

On success, also call Stripe payment_records.report_refund on your account with processor_details.custom.refund_reference = processor_references.refund_id so the PaymentRecord reflects the refund. The payment.refunded webhook (below) also fires — use whichever signal fits your reconciliation flow.

Recommended: reject deliveries where t is older than five minutes, and dedupe on event.id.

FAQ