Stripe Integration for Rain Automation: Connect Payments, Billing, and Bookkeeping
Rain Automation connects to Stripe in two directions. Signed webhook endpoints fire a workflow the moment an event lands (a charge, a refund, a dispute, an invoice, a subscription change), and a scheduled read of your Stripe balance transactions posts revenue, processing fees, refunds, and payouts into double entry bookkeeping. Rain can also charge a saved card off-session through a vaulted Stripe customer, which is how per-transaction purchases inside AgentOS are billed. One thing worth stating plainly: there is no click-to-connect button in a public app directory. Rain's team provisions the restricted key, registers the webhook endpoint, and writes the workflow logic during setup. That is slower to start than a self-serve connector and it is the reason the event coverage is not capped at a fixed trigger list.
How to connect Stripe
Step 1. Confirm which Stripe account Rain is connecting
A business often has more than one: a live account, a test account, and sometimes a second account left over from an old processor migration. Rain connects one live account per environment. If you are running AgentOS, the platform subscription and any per-transaction purchases can sit on the same account or on separate ones, and that decision is made here, not later.
Step 2. Create a restricted API key in Stripe
In the Stripe Dashboard, go to Developers > API keys > Create restricted key. Grant read access to balance transactions, charges, refunds, payouts, customers, invoices, and subscriptions. Grant write access only if a workflow in Step 5 actually needs to create something in Stripe. Name it after the job it does, for example rain-bookkeeping-sync, so a future key rotation has an obvious blast radius. Rain stores the key encrypted at rest, never in source control.
Step 3. Register the signed webhook endpoint
In Stripe, go to Developers > Webhooks > Add endpoint and paste the endpoint URL Rain gives you. Select only the events your workflows consume rather than all events, because every unselected event is one less thing to reason about in a log. Stripe issues a signing secret that starts with whsec_. Every payload Rain receives is verified against that signature before it touches a database, and every event is deduplicated on the Stripe event ID so a retried delivery cannot double-post.
Step 4. Map Stripe activity to your chart of accounts
This step only applies if you are using the bookkeeping side. Each balance transaction type is mapped to a pair of ledger accounts: a charge books gross revenue and splits the per-transaction processing fee into its own expense line, a refund reverses revenue, a payout moves money from the processor balance to your operating bank account. Anything ambiguous, such as an adjustment or a dispute, is written as a draft entry and queued for a human instead of being guessed at.
Step 5. Define the workflows
Name the events you care about and what should happen on each one. This is the part that is worth arguing about, and the examples below are a starting point rather than a menu. If you are new to the exercise, the walkthrough in automation tools for service businesses covers how to pick the first few without automating something you will regret.
Step 6. Run a backfill, then verify against Stripe
The first sync runs over a historical window so your ledger is not starting from an empty month. Then reconcile: the sum of posted revenue, fees, and payouts for a closed period should match the Stripe Dashboard for the same period. If it does not, the difference is almost always an unmapped transaction type sitting in the draft queue, which is exactly where you want it to be sitting. After the backfill, the sync runs on a schedule with a deliberate overlap window, because Stripe does not always list a balance transaction in strict creation order and a narrow window silently drops rows.
Example workflows
Successful charge to Slack and CRM
On a successful charge, post the customer name, amount, and product to a Slack channel, then write the payment back to the customer record in your CRM so sales and support are looking at the same history.
Use case: Revenue visibility
Failed invoice payment to a dunning sequence
When an invoice payment fails, start a recovery sequence that emails the customer with a card update link, pauses the sequence the moment the retry succeeds, and escalates to a human before the subscription is cancelled rather than after.
Use case: Involuntary churn recovery
Dispute opened to fulfillment freeze and evidence packet
A dispute event flags the order, halts any pending fulfillment on that customer, and assembles the evidence Stripe will ask for (receipt, delivery confirmation, terms acceptance timestamp, support thread) into one place before the response deadline.
Use case: Chargeback response
Balance transaction to a journal entry with the fee split out
Every balance transaction becomes a posted double entry journal line. A charge books gross revenue and the processing fee separately instead of booking net, so the fee is visible as a real cost of doing business in your reporting rather than quietly eaten inside a revenue number. Refunds, payouts, and Stripe Billing fees each get their own mapping, and adjustments land in a review queue.
Use case: Bookkeeping accuracy
Late asynchronous payment failure reconciled against a shipped order
Some off-session charges succeed at request time and fail hours later. When that late failure event arrives, the workflow finds the order that was already marked paid, moves it back to unpaid, notifies whoever owns the account, and stops the next fulfillment step if it has not run yet. This is the case a simple charge-succeeded trigger will never catch, and it is the one that costs real money.
Use case: Payment reconciliation
Card on file expiring before the next renewal
Compare each vaulted card's expiry against the customer's next renewal date and reach out while the card still works, instead of finding out through a declined invoice. Cheaper than dunning and far cheaper than a cancellation.
Use case: Preventive retention
Pricing
Connecting Stripe is part of the platform and setup work Rain already does, not a separate add-on you buy. What changes the scope is how many distinct events you want acted on and whether you are also running the bookkeeping sync, since that one needs a chart of accounts mapped to your business rather than a default one. Stripe's own processing and Billing fees are charged by Stripe directly and Rain never marks them up. Those fees are posted to their own expense account so they show up as a line you can actually look at. Current plans and what each includes are on the pricing page.