PayPal to Snowflake integration for analytics-ready payments data

The PayPal to Snowflake integration from Adapters loads transactions, fees, refunds, and payer detail from the PayPal Transaction Search API into Snowflake tables on an incremental schedule, so revenue and reconciliation models read a full history instead of downloading activity reports by hand. Field mapping is no-code.

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 Snowflake by hand costs you

The PayPal Transaction Search API caps each request to a 31-day window, so backfilling a year of activity means chaining many paged calls.
Fees, refunds, and holds sit in separate transaction events, and reconciling them to gross sales in a spreadsheet is slow and error-prone.
Finance needs PayPal alongside Stripe and bank data in one warehouse to see true net revenue, not three separate exports.

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 / SNOWFLAKE

transaction.transaction_id

FCT_TRANSACTION.transaction_id

transaction.amount.value

FCT_TRANSACTION.amount

transaction.initiation_date

FCT_TRANSACTION.created_at

transaction.fee_amount.value

FCT_TRANSACTION.fee

payer.email_address

DIM_PAYER.email

transaction.updated_date

FCT_TRANSACTION.loaded_at

Transforms included

Incremental loads page the PayPal Transaction Search API in 31-day windows using the updated date so each run only pulls new and changed activity; amount and fee strings cast to Snowflake NUMBER, currency codes carry through, ISO 8601 timestamps become TIMESTAMP_NTZ in UTC, and fees join to their transaction so gross, fee, and net models read one deduplicated table.

PayPal to Snowflake in depth

The PayPal side is governed by the Transaction Search window rather than by a published rate limit, and the Snowflake side has one numeric default that silently truncates money. Read from PayPal and Snowflake documentation on 29 August 2026.

Snowflake NUMBER truncates cents unless you set the scale

Snowflake's NUMBER type defaults to (38,0), meaning thirty-eight digits of precision and zero decimal places. A gross amount column created as a bare NUMBER therefore drops the cents from every PayPal transaction, with no error and no warning. Declare NUMBER(18,2) explicitly for gross, fee and net. This single default is responsible for more quiet revenue misstatement in Snowflake than any pipeline bug.

PayPal amounts arrive as decimal strings

PayPal reports money as a string with exactly two digits after the decimal point alongside a separate currency_code, which is the reverse of Stripe's integer minor units. Cast the string to NUMBER(18,2) on load and keep the currency code in its own column. Loading the raw string into a VARCHAR and casting at query time works until somebody sums it and gets an error, or worse, a lexical sort.

The extract is bounded by 31 days and 10,000 records

Transaction Search accepts a maximum range of 31 days per call and returns at most 10,000 records for that range, paged at up to 500 per page. PayPal's documented answer to exceeding the record cap is to shorten the range, since no page reaches record 10,001. Size the windows by transaction volume rather than by month, or a busy period silently returns a partial set.

PayPal publishes no rate limit, so pace by design not by backoff

PayPal's own documentation states it does not publish a rate limiting policy, and throttled calls return HTTP 429 with RATE_LIMIT_REACHED. With no documented ceiling and no documented Retry-After, an adaptive backoff is guesswork. The reliable approach is the one PayPal recommends directly: cache the OAuth token rather than minting one per call, and drive ongoing updates from webhooks instead of polling.

Land files in the range Snowflake actually wants

Snowflake recommends load files of 100 to 250 MB compressed and explicitly advises against files above 100 GB. A transaction extract chunked into 31 day windows naturally produces many small files, which is the inefficient end of that range. Batch several windows into one file before the COPY rather than issuing a COPY per window. The default COPY statement timeout is 24 hours.

Identifiers fold to uppercase here, unlike Postgres

Snowflake folds unquoted identifiers to uppercase while PostgreSQL and Redshift fold to lowercase. A loader written against a Postgres target that creates paypal_transaction will find PAYPAL_TRANSACTION in Snowflake, and a query quoting the lowercase name returns nothing. Pick a convention before the first load rather than after the first failed join.

Allow for the three hour reporting delay

PayPal states an executed transaction can take up to three hours to appear in the list transactions call, and history is limited to the previous three years. A scheduled load whose window ends at run time misses the trailing three hours on every run. End each window in the past and re-read the overlap, upserting on transaction id so the repeat costs nothing.

Reconcile against a payout, not against a day

A payout spans several days of activity and can straddle a month boundary, so joining transactions to deposits by date always leaves a residual that looks like missing data. Reconcile on the payout or settlement identifier instead. Related routes: PayPal to Postgres, and the wider category on Snowflake 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 Snowflake 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.

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

PayPal to Snowflake sync: common questions

How do you load PayPal transactions into Snowflake?

Through the PayPal Transaction Search API, which returns transaction level detail with fees, then staged as files and merged into Snowflake. PayPal has no direct Snowflake integration, so a connector authenticates with your REST app credentials, pages through the transaction history, and maintains an incremental watermark on transaction date.

How far back can you pull PayPal transaction history?

The Transaction Search API limits how far back and how wide a single query can reach, so a multi year backfill has to be chunked into date windows rather than requested in one call. Plan the initial load as a sequence of windows with retry handling, and keep the incremental job on a short rolling window afterwards.

How should PayPal fees be modeled in Snowflake?

As their own column and their own amount, never netted into the gross. PayPal deducts fees before settlement and applies additional fees on currency conversion, so a table with only the net figure cannot reproduce gross revenue or fee ratios. Keep gross, fee and net as separate numeric columns.

What data type should PayPal amounts use in Snowflake?

An explicit NUMBER with precision and scale, such as NUMBER(19,4). Snowflake's NUMBER type defaults to a precision and scale of (38,0), which silently truncates the cents if a loader relies on the default. Currency codes belong in their own column so multi currency accounts can be reported correctly.

How does the PayPal to Snowflake sync work?

Is there a prebuilt PayPal connector for Snowflake?

Yes. This PayPal to Snowflake 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 Snowflake 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 Snowflake?

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 Snowflake?

No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental loads page the PayPal Transaction Search API in 31-day windows using the updated date so each run only pulls new and changed activity; amount and fee strings cast to Snowflake NUMBER, currency codes carry through, ISO 8601 timestamps become TIMESTAMP_NTZ in UTC, and fees join to their transaction so gross, fee, and net models read one deduplicated table.

More pairs from the API connector library

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

PayPal and Snowflake, 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.