Square to Postgres integration for a queryable payments replica
The Square to Postgres integration from Adapters syncs payments, orders, refunds, customers, and payouts from the Square API into your own Postgres tables on an incremental schedule, so reporting and app features query transaction data with plain SQL instead of paging the Square API live. Field mapping is no-code, so try it against sample records in the live demo.
No credit card required.
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
Last updated September 2026
What running Square to Postgres by hand costs you
- Square reports cannot join to your product, inventory, or accounting tables, so cross-location margin and cohort questions get answered by exporting CSVs.
- The Square API pages with cursors and returns money as integer cents in a nested money object, so a hand-rolled export mishandles multi-location and currency every time.
- Payments get refunded and disputed after they settle, and a one-time export into Postgres is stale before the next payout reconciliation.
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 / SQUARE
Output / POSTGRES
Transforms included
Incremental loads walk the Square cursor and filter on the updated-at range so only changed payments come back; the nested total_money object flattens to an integer cents column plus a currency code, buyer and location ids land as foreign keys, the RFC 3339 timestamps parse to TIMESTAMPTZ in UTC, and writes upsert with ON CONFLICT on the Square payment id so a retried or overlapping window never double-inserts a row.
Square to Postgres in depth
Payments into your own database, which is the most flexible target and the one with the fewest guardrails. Nothing here stops you storing money in a type that loses it. Read from Square and PostgreSQL documentation, facts current as of 1 September 2026.
Square money is an integer in the smallest denomination
Square documents that a monetary amount is specified in the smallest denomination of the currency, so USD amounts are cents and 4250 means $42.50. Currencies such as the Japanese Yen are zero-decimal, where the smallest unit is one yen and no division applies. Any pipeline that hardcodes a divide by 100 misstates every zero-decimal currency by a factor of one hundred, with no error raised anywhere. Branch on the currency code.
The last page of a Square result set has no cursor
Square paginates with an opaque cursor. The first call omits it, each response carries the cursor for the next page, and the last page does not include one. That absence is the terminator, and it is the single most common place this integration breaks: code that loops while a cursor is truthy works, code that loops on a fixed page count silently drops the tail of the data. Default and maximum page sizes vary per endpoint, so read the limit for each one rather than assuming a shared value.
Square does not publish a rate limit number, so do not hardcode one
We are not going to print a figure here, because Square does not publish one and its own developer forums carry unanswered questions asking for it. That is worth stating plainly rather than repeating a number from a blog post. The correct design is to treat the rate limit as unknown and discoverable: handle the rate limit error explicitly, back off exponentially with jitter, and let observed throughput settle wherever it settles rather than tuning to a constant that was never documented.
Store money as numeric, or keep the integer cents
Two defensible choices. Keep Square's integer cents in a bigint and divide only at presentation time, which is exact by construction and matches what the API sends. Or use numeric(19,4), which is exact decimal arithmetic. What you must not use is double precision, where most decimal fractions have no exact representation and sums drift, nor the PostgreSQL money type, whose fractional precision comes from the database lc_monetary setting and therefore travels badly between servers.
Upsert on the Square payment id
Cursor pagination plus retries means the same payment will be delivered twice at some point. A unique index on the Square payment id with INSERT ... ON CONFLICT DO UPDATE makes that harmless. Without it, the duplicates are invisible until somebody sums a column and gets a number that is slightly too large, which is a much more expensive way to find out.
Timestamps belong in timestamptz
Square timestamps carry an offset. Store them in timestamptz and not in a naive timestamp, because dropping the offset means the daily boundary in your reports depends on the server timezone. A day boundary that moves is the sort of bug that produces two reports which disagree by one day's revenue and no obvious reason why.
Index for the query you actually run
Payments tables are almost always queried by date range and by location. An index on the created timestamp, and a composite index on location plus timestamp, covers nearly everything a payments dashboard asks for. Add them before the table is large, because building an index on a table with years of payment history is an outage-shaped event. Related routes: Stripe to Postgres and Postgres 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 Square and Postgres 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 replicating Square payments to Postgres covers the field-by-field detail, the failure cases, and what changes at volume.
Square to Postgres sync: common questions
How do I sync Square to Postgres?
Connect the Square account, choose payments, orders, line items, refunds, customers and settlements, map them onto Postgres tables, and pick a schedule. Each run upserts on the Square id with ON CONFLICT, so a re-run repairs the table rather than duplicating the day's sales.
How should Square money amounts be stored in Postgres?
Convert from the smallest currency unit and store NUMERIC(19,4). Square returns money as an integer amount plus a currency code, so $12.75 arrives as 1275. Keeping the currency in its own column matters for any location taking more than one, and NUMERIC keeps the arithmetic exact where a float would not.
Why do Square net deposits not match the sum of payments?
Processing fees and settlement timing. A day of payments is not the deposit that lands in the bank: fees come out, refunds net against it, and the settlement covers a cut-off window that rarely matches a calendar day. Load payments, fees and settlements as separate tables and reconcile on the settlement id rather than by date.
Can I combine Square with online sales in the same Postgres database?
Yes, and it is the usual reason for doing this. Land Square alongside your ecommerce and payment processor tables with a consistent order and customer key, and total revenue becomes one query instead of three exports. The work is agreeing the shared key up front, because retail and online systems rarely identify a customer the same way.
How does the Square to Postgres sync work?
The Square to Postgres integration from Adapters syncs payments, orders, refunds, customers, and payouts from the Square API into your own Postgres tables on an incremental schedule, so reporting and app features query transaction data with plain SQL instead of paging the Square API live. Field mapping is no-code, so try it against sample records in the live demo.
Is there a prebuilt Square connector for Postgres?
Yes. This Square to Postgres 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 Square Postgres 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 Square to Postgres?
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 Square and Postgres?
No. Fields are auto-mapped the moment you pick the pair, and you can rewire any mapping visually before the first sync. Incremental loads walk the Square cursor and filter on the updated-at range so only changed payments come back; the nested total_money object flattens to an integer cents column plus a currency code, buyer and location ids land as foreign keys, the RFC 3339 timestamps parse to TIMESTAMPTZ in UTC, and writes upsert with ON CONFLICT on the Square payment id so a retried or overlapping window never double-inserts a row.
More pairs from the API connector library
Browse the full api connector library, or request a pair you do not see.
Square and Postgres, finally in agreement
Map the pair once and let it sync on schedule. Flat price from $49 a month, no per-task fees.
No credit card required.