Stripe

Stripe is the payment processor; AppBO is where the customer relationship and the automation live. On the Stripe side sit customers, payment methods, payment intents, subscriptions, invoices, refunds and disputes, plus the risk and compliance machinery that comes with holding card data. On the AppBO side sit the contact, the order or opportunity, the pipeline, and the workflows that need to know whether money actually arrived.

You wire them together so that a payment is an event in the customer's story rather than a number in a separate dashboard. Connected, a successful charge can move the opportunity, grant access, start the fulfillment sequence and stop the chase-up reminders. A failed renewal can trigger a dunning sequence that uses the same email and SMS templates as everything else. A refund can tag the contact and remove them from the upsell campaign. Disconnected, somebody checks two systems and reconciles by hand.

Stripe is usually the default choice for card payments in AppBO because the connection covers the broadest surface. One-off payments, subscriptions, invoices and the checkout experience on funnel and order pages, and because its webhook catalog is detailed enough to drive automation precisely. The work of integrating well is less about connecting it, which is quick, and more about deciding which Stripe events are the truth, and making sure the platform's records follow them rather than drifting.

1. Have the Stripe account ready first: business details verified, a payout bank account attached, and the statement descriptor set to something customers will recognize on a card statement. An unverified account will take payments and withhold payouts.
2. Decide which system owns the product catalog. Products and prices defined in Stripe and products defined in the platform's own payment settings can both work, but you must pick one as the source of truth or your reporting will never reconcile.
3. In the relevant AppBO sub-account, open the payments settings and start the Stripe connection. Complete Stripe's authorization flow, signing in to the Stripe account that should receive the funds.
4. Check which Stripe account you connected. If you administer several, confirm the account identifier shown after connection is the intended one before taking a single live payment.
5. Set the connection's mode deliberately. Connect in test mode first and keep it there until the whole flow is proven; switching to live is a conscious step, not an afterthought.
6. Configure the payment experience: which currencies, whether to collect billing address, whether to save payment methods for future use, and which wallets or alternative methods to enable. Enable only what you can support operationally.
7. Create the product or price records in whichever system you chose as the catalog owner, and attach them to the funnel step, order form or invoice template that will sell them.
8. Confirm the webhook path from Stripe. The platform registers what it needs during connection; if you also need events in your own system, register a separate endpoint in Stripe rather than intercepting the platform's, and verify its signature using the signing secret Stripe issues for that endpoint.
9. Build the automation on payment events rather than on page behavior. Trigger the fulfillment workflow from the payment-succeeded signal, not from the visitor reaching a thank-you page. A visitor can reach that page without paying, and a payment can succeed without them reaching it.
10. Build the failure paths too: a failed payment workflow, a subscription past-due workflow, and a refund workflow that reverses whatever access the success path granted.
11. Decide how the contact and the Stripe customer are matched, normally email, and store the Stripe customer identifier on an AppBO custom field so later lookups are exact rather than fuzzy.
12. Run a full test-mode transaction with Stripe's test cards: a successful card, a declined card, and one requiring additional authentication. Confirm each produces the record and the workflow you expected.
13. Test the subscription lifecycle in test mode by advancing a subscription through a renewal and a failure, and confirm the dunning workflow fires and the access change happens.
14. Switch to live mode and make one small real payment with a real card, end to end. Confirm the charge appears in Stripe, the record appears in the platform, the workflow ran, and the funds show as pending payout. Then refund it and confirm the reversal path.
15. Put monitoring on the things that fail silently: webhook delivery failures in the Stripe dashboard, payments recorded in Stripe with no corresponding platform record, and subscriptions in a past-due state with no active dunning.

Platform to Stripe

• Payment intents created when a customer submits an order form, funnel checkout step or invoice payment.
• Customer records, typically keyed on email, with name and billing details as collected.
• Subscription creation and changes where the platform initiates them, referencing a price.
• Invoice and amount details for a requested payment, plus metadata identifying the contact and the originating page.
• Refund requests initiated from the platform, where that action is available.

Stripe to the platform

• Payment outcome events: succeeded, failed, requires action, canceled.
• Subscription lifecycle events: created, renewed, payment failed, past due, canceled.
• Invoice events: created, paid, payment failed, voided.
• Refund and dispute notifications.
• The transaction record that populates the platform's payment and order views, and the values workflows branch on.

What does not move

• Card numbers. The card data is captured by Stripe's own elements and never lands in the platform, which is precisely what keeps the compliance burden with Stripe.
• Stripe's risk, radar and dispute-evidence tooling. Fraud decisions stay in Stripe.
• Payout and balance detail. Reconciliation of what hit the bank is a Stripe and accounting task, not a platform one.
• Historical transactions from before the connection. Nothing backfills automatically.
• Tax determination and filing, beyond whatever tax configuration each side has been given.

Scenario: a customer buys a monthly membership on a funnel checkout step, and the first renewal fails.

1. The customer completes the checkout step. The platform creates a payment intent with Stripe for the membership price and the Stripe payment element collects the card in the browser.
2. The card requires additional authentication. Stripe presents the challenge inline, the customer completes it, and the payment intent succeeds.
3. Stripe creates the customer and the subscription, and emits payment and subscription events.
4. The platform records the transaction against the contact, and writes the Stripe customer identifier to the custom field reserved for it.
5. An AppBO workflow triggered by successful payment fires: it tags the contact member-active, moves the opportunity to Won, sends the receipt and welcome email, and grants access to the members area.
6. One month later Stripe attempts the renewal. The card has expired and the charge fails. Stripe emits an invoice-payment-failed event and marks the subscription past due.
7. A workflow triggered by that failure removes the member-active tag, applies member-past-due, and starts a three-step dunning sequence. Email immediately, SMS after two days, a call task for the account manager after five. Each carrying a link to the payment-method update page.
8. Stripe's own retry schedule attempts the charge again in the meantime, independently of the dunning messages.
9. On day three the customer updates their card. Stripe retries and the charge succeeds, emitting a payment-succeeded event.
10. A workflow on that event removes member-past-due, restores member-active, cancels the remaining dunning steps and the call task, and restores members-area access.
11. A month later the customer disputes a charge. Stripe emits a dispute event; a workflow tags the contact, removes them from the upsell campaign, and raises a task for finance to submit evidence in Stripe, where the dispute is actually handled.

Rate limiting

Stripe rate limits its API, and the live and test modes have separate budgets. A bulk operation (migrating subscriptions, backfilling customers) needs pacing and backoff; consult Stripe's current published limits rather than assuming. On the platform side, each payment event that triggers a workflow consumes execution budget, so a high-volume store should keep its payment workflows lean.

Retries and idempotency

Stripe supports idempotency keys on requests, and its webhooks are delivered at least once with automatic retries over an extended window. Both facts matter. Any handler you write must dedupe on the Stripe event identifier, because the same event will arrive more than once. Workflows triggered by payment events need the same discipline: a fulfillment workflow that can run twice will ship twice. Stripe's own smart retry schedule for failed subscription charges runs independently of your dunning messages, so coordinate the two or customers get asked to pay after they already have.

Field mapping traps

Amounts are in the currency's smallest unit in Stripe. A mismatch here is the single most expensive mapping error in payments, so verify against a real transaction rather than reasoning about it. Contact-to-customer matching is normally by email, which breaks when the customer pays with a different address than the one on their contact record; store the Stripe customer identifier to make later lookups exact. Metadata is how you carry your own identifiers through Stripe, and it is worth populating from the start because you cannot retroactively add it to past charges.

Duplicate creation

Duplicate Stripe customers appear when the same person pays twice with different email capitalization or a different address, and duplicate contacts appear when a payment arrives for an email that already exists in a different form. Normalize email before matching, and reconcile on the stored customer identifier.

Test versus live

Stripe's two modes have separate keys, separate data and separate webhook endpoints, and this is the most common place integrations break on launch day. A connection left in test mode takes no real money while looking entirely successful; a live connection tested with a real card takes real money. Confirm the mode explicitly before and after go-live, and keep the test-mode flow available for regression testing afterwards.

Auth and connection expiry

The connection between the platform and Stripe can be broken by someone disconnecting the app in either system, by a Stripe account being restricted, or by API key rotation. The symptom is payments failing at checkout or events no longer arriving, so alert on both. Also watch for Stripe API version differences: a webhook payload is rendered at a version, and a handler written against an older shape can misparse a newer one.

What commonly breaks

• Fulfillment driven by the thank-you page rather than the payment event, so unpaid visitors get access and paying customers who closed the tab do not.
• A connection left in test mode after launch.
• Webhook events failing silently, visible only in Stripe's own delivery log.
• Currency smallest-unit mistakes producing charges off by a factor of a hundred.
• No refund or dispute path, so access granted on payment is never revoked.
• Dunning sequences running in parallel with Stripe's own retries and contradicting each other.
• Subscription changes made directly in Stripe without the platform learning about them, leaving tags and access stale.