Stripe connector

The Stripe connector lets a Neblex workflow or agent listen to Stripe's event stream and act on it: 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.

• Each connection is set to test or live mode, so you build against test data and promote the same flow to live through environments
• Every write sends an idempotency key derived from the run, so a retried or replayed step is a no-op rather than a second charge
• Webhook signatures are verified against the signing secret before a flow runs
• One connector powers deterministic workflows, agent tool calls, and scheduled reconciliation jobs, all in the same run log

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

• Reconcile revenue without a spreadsheet.
• Keep sales and success in the loop.
• Let support resolve billing safely.

A real flow finance teams turn on first, with the actual field-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 review queue.

1. 1Trigger: Event received for invoice.paid, carrying the invoice, its customer, and amount_paid in cents.
2. 2Identify: read customer.metadata.erp_customer_id and invoice.metadata.erp_invoice_id, set on creation by the billing flow.
3. 3Branch: if either ID is missing, post the invoice to the #billing-review queue with the Stripe link and stop.
4. 4Fees: Get object by ID on the related balance transaction to read fee and net.
5. 5Write: create a customer payment in the ERP, mapping erp_customer_id → entity, erp_invoice_id → applied invoice, net / 100 → payment amount, fee / 100 → bank fee line, invoice.id → external reference.
6. 6Idempotency: the write uses the Stripe event ID as its key, so a redelivered event does not post a second payment.

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 queued 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 stream into Snowflake for revenue and retention analysis. (Data)

The core payment and billing objects are supported for read and write. Events cover essentially every object type Stripe emits.

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 restricted API key, so it holds only the permissions you grant it, per resource.

• Restricted API key. Grant read or write per resource type. A reconciliation flow needs read on invoices and balance transactions and nothing else.
• Test and live isolation. A connection is bound to one mode. Test-mode runs cannot touch live data, and promotion is an environment change, not a code change.
• Webhook endpoints. A flow can expose a webhook endpoint for Stripe to call, protected by an API consumer key with per-consumer rate limits, quotas, and metering.
• Full audit trail. Every event, read, and write, with the object ID and the idempotency key, flows into the same Neblex audit trail as every other connector.

The shape of the vendor's limits, as published at the time of writing. Verify the exact figures for your plan; they change without notice. Neblex honors the vendor's own rate-limit and retry signals and backs off within them.

• Live mode allows roughly 100 read and 100 write requests per second, with test mode lower. The connector paces to stay under the returned limit
• 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 a flow fails, so failures are recoverable but must be idempotent
• Amounts are in the currency's smallest unit, for example cents, and the connector does not silently rescale them