PayPal to BigQuery integration for analytics-ready payments data

The PayPal to BigQuery integration from Adapters loads transactions, fees, refunds, and payouts from the PayPal Transaction Search API into partitioned BigQuery tables on an incremental schedule, so revenue, net-settlement, and cohort models run on a full history instead of a manual CSV export. Field mapping is no-code, so try it against sample records in the live demo.

Try it in the live demo

No credit card required.

Input

Output

Field mapping auto-plugged · tap a port to rewire

5 sample records ready

Last updated September 2026

What running PayPal to BigQuery by hand costs you

The PayPal Transaction Search API returns data in paged windows with rate limits and a limited lookback, so backfilling a full transaction history into BigQuery by hand is fiddly to script.
PayPal reports gross amount, fee, and net separately, so a naive load into BigQuery leaves you reconciling fees before revenue and settlement numbers agree.
Refunds, chargebacks, and reversals land as later events against an earlier sale, and a flat dump into BigQuery misses those adjustments unless you re-pull the window.

The field mapping, out of the box

These cables are pre-wired when you pick the pair. Rewire any of them, or add your own, in the same visual data mapping tool you use for every adapter.

Input / PAYPAL

Output / BIGQUERY

transaction_info.transaction_id

fct_transaction.transaction_id

transaction_info.transaction_amount.value

fct_transaction.gross_amount

transaction_info.fee_amount.value

fct_transaction.fee_amount

transaction_info.transaction_status

fct_transaction.status

payer_info.email_address

dim_payer.email

transaction_info.transaction_updated_date

fct_transaction.loaded_at

Transforms included

Incremental loads use the transaction updated date to re-pull the settlement window so refunds and reversals flow through; gross, fee, and net amounts cast to BigQuery NUMERIC with net computed as gross minus fee, currency codes stay ISO 4217, timestamps become TIMESTAMP in UTC, tables partition by transaction date, and writes MERGE on the transaction id so revenue and settlement models read one deduplicated history.

PayPal to BigQuery in depth

One PayPal constraint and one BigQuery quota decide this route: a 31 day extract window and a hard ceiling on load jobs per table per day. Read from PayPal and Google Cloud documentation on 29 August 2026.

Money belongs in NUMERIC, never FLOAT64

BigQuery NUMERIC gives 38 digits of precision and 9 of scale, which represents currency exactly. FLOAT64 cannot represent most decimal fractions exactly, so a sum over a few hundred thousand PayPal transactions drifts away from the true total by amounts that are small individually and indefensible in aggregate. PayPal already hands you a decimal string, so casting it to NUMERIC is both the correct and the easy path.

1,500 load jobs per table per day is easy to exhaust

BigQuery permits 1,500 load jobs per table per day and 100,000 per project per day. A backfill that steps 31 day windows and issues one load job per window is fine. A near-real-time job loading every minute burns the daily table quota in twenty-five hours of running, and it fails for the rest of the day. Batch into fewer, larger loads, or stream instead of loading.

The extract window is 31 days and 10,000 records

Transaction Search accepts a maximum date range of 31 days per call and returns at most 10,000 records within it, paged at up to 500 per page against a default of 100. Beyond the record cap there is no further page to request, and PayPal's documented remedy is to shorten the range. Drive window size from transaction volume, because a high-volume merchant exceeds 10,000 well inside a month.

PayPal does not publish a rate limit at all

Unusually for a payment platform, PayPal's documentation states that it does not publish a rate limiting policy, and simply notes it may throttle traffic that appears abusive, returning HTTP 429 RATE_LIMIT_REACHED. There is no documented per-second figure to design against and no documented Retry-After. Follow the two practices PayPal does document: cache the OAuth token, and use webhooks rather than polling for ongoing changes.

Amounts are decimal strings with a separate currency code

PayPal returns money as a string carrying exactly two digits after the decimal point plus a separate currency_code. This is the opposite of Stripe's integer minor units, so a shared normalization helper written for Stripe will divide PayPal amounts by a hundred and understate revenue silently. Keep gross, fee and net as three separate NUMERIC columns rather than netting them at load time, so a later question about effective fee rates is a query rather than a re-extract.

Partition by transaction date, not by load date

Partitioning the table on the PayPal transaction timestamp keeps finance queries cheap, because almost every question about payments is bounded by a period. Partitioning on ingestion time instead means a query for last March scans everything ever loaded. Given the three hour reporting delay, a late-arriving transaction lands in an older partition, which is exactly the behaviour you want and exactly why an upsert on transaction id matters.

Three hours late, three years back

PayPal states an executed transaction takes up to three hours to appear in the list transactions call, and the call serves only the previous three years. End each scheduled window at least three hours in the past, and treat the first backfill as your only chance at the oldest data, because it ages out of the API permanently.

Verify by summing, not by checking the job

A load job marked successful proves the file parsed. Compare the row count and the gross total in BigQuery against the same period in the PayPal dashboard before trusting the table. Related routes: PayPal to Snowflake, and the category overview on BigQuery ETL tools.

How it goes live

Three steps, minutes end to end, covered by flat data integration pricing from $49 a month.

STEP 01

Pick the pair

Connect PayPal and BigQuery with scoped credentials. About a minute each.

STEP 02

Confirm the mapping

The cables above are pre-wired. Adjust any field, preview the transform on sample records, done.

STEP 03

Schedule the sync

Hourly down to every minute, with retries, alerting, and a full log on every run.

Prefer to understand the moving parts first? Our long-form guide to the PayPal to BigQuery guide covers the field-by-field detail, the failure cases, and what changes at volume.

Try it in the live demo Preloads PAYPAL → BIGQUERY with sample records

PayPal to BigQuery sync: common questions

How do I get PayPal transactions into BigQuery?

Connect the PayPal account, pull the transaction and settlement data through the reporting API, map the fields onto BigQuery columns, and schedule it. Adapters walks the date windows the API requires, normalizes fees and gross versus net amounts into separate columns, and merges on the PayPal transaction id so a re-run does not duplicate rows.

Why does PayPal revenue in BigQuery not match the PayPal dashboard?

Almost always gross versus net. PayPal reports a gross amount, a fee and a net, and a pipeline that loads only one of them will disagree with whichever figure the dashboard is showing. Currency conversion adds a second layer, because a converted transaction carries both the original and settled amounts. Load all three columns and let the model choose.

How far back can PayPal transaction history be loaded?

The transaction search endpoint limits how wide a date range a single request can cover, so a full history backfill is a sequence of windowed requests rather than one call. That is fine when a tool chains them for you and painful when you are scripting it, because you also have to handle throttling and partial windows without gaps.

Should PayPal amounts be stored as NUMERIC in BigQuery?

Yes. Use NUMERIC for gross, fee and net, and keep the currency code in its own column. BigQuery NUMERIC holds 38 digits with 9 decimals, which is exact for money. Storing amounts as FLOAT64 introduces rounding that shows up as pennies of variance in a monthly reconciliation and undermines confidence in the data.

How does the PayPal to BigQuery sync work?

Is there a prebuilt PayPal connector for BigQuery?

Yes. This PayPal to BigQuery connector ships prebuilt: the field mapping is wired the moment you pick the pair, transforms are included, and you can try it against sample records in the live demo. No code or engineering sprint required.

How much does the PayPal BigQuery integration cost?

Pricing is flat and monthly: Starter at $49, Growth at $149, Scale at $399. Every plan includes this pair, visual field mapping, and per-record logs. There are no per-task or per-row fees, so the bill stays the same as volume grows.

How often can Adapters sync PayPal to BigQuery?

Hourly on Starter, every 5 minutes on Growth, and down to every minute on Scale. Failed records retry automatically with backoff, and alerting plus a full per-record log come standard on every run.

Do I need to write code to connect PayPal and BigQuery?

No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental loads use the transaction updated date to re-pull the settlement window so refunds and reversals flow through; gross, fee, and net amounts cast to BigQuery NUMERIC with net computed as gross minus fee, currency codes stay ISO 4217, timestamps become TIMESTAMP in UTC, tables partition by transaction date, and writes MERGE on the transaction id so revenue and settlement models read one deduplicated history.

More pairs from the API connector library

Browse the full api connector library, or request a pair you do not see.

PayPal and BigQuery, finally in agreement

Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.

Try the live demo

No credit card required.