Skip to content

Integration

PayPal + Bastle

What syncs from PayPal, what it makes possible, and how to connect it.

Beta

This connector works and can be connected today, with edge cases still being closed. Check the first month against the source before you rely on it.

What does the PayPal integration do?

The PayPal integration reads billing plans, subscriptions, transactions and refunds through PayPal's REST APIs using OAuth2 client credentials, and ingests webhooks verified against a registered webhook id. It covers PayPal Subscriptions rather than one-off checkout volume, which is what makes recurring revenue metrics meaningful on a PayPal book.

What syncs

Bastle reads the following from PayPal and normalises it into the same entities every other source produces. Ingestion is read-only: nothing is created, changed or cancelled upstream.

  • Billing plans → Bastle plans, with the regular billing cycle mapped to interval and interval count. Plans whose cycles are omitted from the list response are fetched individually.
  • Subscriptions with their status and billing history.
  • Captured payments → charges, and refunds against them.
  • Subscription lifecycle events — created, activated, cancelled, suspended, payment failed — from the webhook stream.
  • Cadence: webhook-driven for changes; historical import run manually today.

Once connected

What PayPal data unlocks

Connecting a source is not the point; what you can answer afterwards is. These are the questions this data makes answerable.

Recurring revenue from PayPal Subscriptions

PayPal reports payments, not subscription analytics. Bastle normalises billing plans and subscriptions into the same MRR, churn and retention model used for every other source.

Suspensions handled as their own state

A suspended PayPal subscription is neither active nor cancelled. Treating it as either produces a wrong churn number, so it is tracked distinctly.

Sandbox parity

The connector targets PayPal's sandbox host when the source is configured for it, so the mapping can be verified against test subscriptions first.

Setup

Connecting PayPal

The whole flow, start to first chart. No implementation call and no data engineer.

  1. Create a REST app in the PayPal developer dashboardIt yields a client id and secret. Bastle exchanges them for an access token per run using the client credentials grant.
  2. Register a webhook and note its idPoint it at /api/webhooks/paypal and subscribe to the billing subscription and payment events. PayPal's signature verification requires the webhook id, so record it.
  3. Connect PayPal in Settings → IntegrationsEnter the client id, secret and webhook id, and set the environment to live or sandbox to match the credentials.
  4. Ask us to run the historical importBackfill runs manually during onboarding while the scheduled runner is being wired.

Subscriptions, not checkout volume

PayPal handles two very different kinds of money movement: one-off checkout payments and recurring billing subscriptions. Only the second produces recurring revenue, and this connector is built around it. If your PayPal account is mostly one-off transactions, connecting it will produce accurate charge history and very little MRR, which is the correct answer rather than a bug.

Webhook verification

PayPal signs webhook deliveries and verifies them against a registered webhook id, so that id is required rather than optional. Without it there is no way to distinguish a genuine PayPal delivery from anything else that can reach a public URL, and Bastle will not process unverified events.

Token handling

Access tokens are minted per run from the client credentials, cached for the duration of that run, and re-minted on expiry. They are never persisted, so a leaked database row cannot yield a usable PayPal token.

What "beta" means here

The connector is written and the inbound webhook route verifies signatures and writes normalised rows, so a connected account keeps up with changes as they happen. What is not self-serve yet is the historical backfill: the code that walks your provider's API from the beginning exists in the connector, but the scheduled runner that triggers it is still a stub, so first-time imports are run by hand with us. Expect to email someone once during setup, and expect that to stop being true.

Bastle is free while in beta, connectors included. There is no tier that unlocks a provider.

Related

Other sources

Companies billing through PayPal usually have at least one of these in the stack too.

PayPal and Bastle: common questions

Does Bastle track one-off PayPal payments?

Captured payments are imported as charges and count towards net revenue, but they do not create recurring revenue. MRR on a PayPal source comes from PayPal Subscriptions; an account that is mostly one-off checkout volume will show charge history with little MRR.

Why does Bastle need my PayPal webhook id?

PayPal's signature verification is performed against the registered webhook id. Without it there is no way to prove a delivery came from PayPal, and Bastle rejects events it cannot verify rather than trusting them.

How does a suspended subscription affect churn?

It is tracked as suspended rather than being forced into active or cancelled. Counting suspensions as churn overstates cancellation, and counting them as active overstates MRR; keeping the state distinct means you can decide the policy rather than inherit ours.

Does Bastle write anything back to my billing provider?

No. Bastle reads from your billing provider and never mutates it. It does not cancel subscriptions, apply coupons, retry charges through the provider, or update stored cards. Read-only API credentials are enough for every provider connector, and using them is the recommended setup.

Connect PayPal and see your own history.

Bastle backfills what PayPal will serve, then keeps current over webhooks — usually a couple of minutes before the first real chart. Free while in beta, no card required.