Stripe connector

The Stripe connector lets a Neblex workflow or agent act on Stripe's events and data: reconcile a paid invoice into the ledger, chase a failed subscription payment, provision access on a completed checkout, or answer a billing question, without a webhook receiver to build and keep alive.

• A Webhook trigger set to Auto Register With Stripe creates the Stripe webhook endpoint when the flow is activated, and removes it when the flow is turned off
• Incoming events are verified with the Stripe-Signature header before the flow runs
• Turn on Idempotency key on a write step, and a retried or resumed step sends the same key, so Stripe applies the change only once
• Each connection uses a test or live key, so you build against test data and promote the same flow to live through environments

The three jobs this connector is picked for most often, and what each one gets you.

• Reconcile revenue without a spreadsheet. Paid invoices and payouts are booked into the ERP or accounting system against the right open invoice, with fees split out.
• Keep sales and success in the loop. Failed payments and cancellations update the CRM account and notify the owner, so nobody learns about churn from a report.
• Let support resolve billing safely. An AI agent looks up invoices and payments for a customer, while refunds and other writes wait for a person to approve them.

A real flow finance teams turn on first, with the actual step-level detail.

Every paid Stripe invoice booked against the right open ERP invoice

On invoice.paid, Neblex finds the matching open AR invoice in the ERP and records a customer payment for the net amount, sending anything it cannot match to a person for review.

1. 1
   Trigger: a Webhook trigger with Auto Register With Stripe for invoice.paid, carrying the invoice, its customer, and amount_paid in cents.
2. 2
   Identify: read customer.metadata.erp_customer_id and invoice.metadata.erp_invoice_id, set on creation by the billing flow.
3. 3
   Branch: if either ID is missing, a Wait for form step sends the invoice to the billing team for review with the Stripe link.
4. 4
   Fees: Get balance transaction for the invoice's charge to read fee and net.
5. 5
   Write: upsert a customer payment in the ERP keyed on the Stripe event ID, mapping erp_customer_id → entity, erp_invoice_id → applied invoice, net / 100 → payment amount, fee / 100 → bank fee line.
6. 6
   No double booking: because the payment is keyed on the event ID, a redelivered event updates the same payment instead of posting a second one.

Common patterns other teams start from with this connector.

• Revenue reconciliation. Paid invoices and their fees are booked into NetSuite against the matching open invoice, with unmatched items sent to a person for review. (Finance)
• Stripe to the books. Charges, refunds, and payouts sync into QuickBooks as sales receipts and deposits, categorized by product. (SMB finance)
• Failed payment recovery. A failed subscription payment opens a task for the account owner, posts to Slack, and runs a dunning sequence until it resolves. (RevOps)
• Billing data to the warehouse. Customer, subscription, and invoice events are loaded into Snowflake for revenue and retention analysis. (Data)

The core payment and billing objects are supported for read and write, and the connector has ready-made triggers for the events teams use most.

Commonly used objects

Customer, PaymentIntent, Charge, Refund, Invoice, Invoice Item, Credit Note, Subscription, Subscription Item, Price, Product, Coupon, Checkout Session, Payout, Balance Transaction, Dispute, Payment Method, Event

Use the metadata field on customers, invoices, and subscriptions to carry your own system's IDs, so a workflow can match a Stripe object back to a record without a separate mapping table.

The connection uses a Stripe secret or restricted key, so it holds only the permissions that key has.

• Restricted keys. Grant read or write per resource type. Auto Register needs write access to webhook endpoints; the rest of a reconciliation flow needs read on invoices and balance transactions.
• Test and live isolation. A connection uses one key, so test-mode runs cannot touch live data, and promotion is an environment change, not a code change.
• Verified events. Webhook deliveries from Stripe are checked against the endpoint's signing secret before a flow runs.
• Run history. Every run shows each step's status and errors; record data from successful runs is kept when the flow is set to keep run data for replay.

The shape of Stripe's limits, as published at the time of writing. Verify the exact figures for your account; they change without notice.

• Live mode allows roughly 100 read and 100 write requests per second, with test mode lower. Rate-limited reads are retried with backoff, and writes are retried when the step sends an idempotency key
• The Search API is eventually consistent, lagging writes by up to a minute, so a flow that just created an object should read it by ID, not search for it
• Search and list endpoints return up to 100 results per page with cursor pagination
• Webhook events are retried with exponential backoff for up to three days if delivery fails, so a flow must be safe to run twice on the same event
• Amounts are in the currency's smallest unit, for example cents, and the connector does not rescale them