Pilot estimate
About 10 minutes after adapter validationAn estimate for a future approved pilot, not an available setup path.
Pre-production blueprint · Square POS (cloud API)
Square POS connection validation blueprint
Status: connection blueprint, not a live connector. This page documents the intended read-only OAuth path. StoreRounds does not yet offer a production Square adapter.
Square keeps sales in its cloud and exposes an API. The planned path needs no store-side install or database user: a future adapter would use Square's sign-in, a short list of read-only permissions, selected locations, and a read-back against the store's own closed-day report.
Written for the owner, not the engineer. In a future approved pilot, Square would keep the owner's password and issue StoreRounds a revocable token limited to the approved read scopes. This is the intended boundary, not a claim that the connection is available now.
Difficulty
Owner-friendlyA few clicks and one approval screen. No coding.
A future pilot would require
Two thingsA Square account owner or admin and a founder-approved StoreRounds pilot. Do not enter credentials from this page.
Running example throughout: a fictional two-store chain, Aurora Beauty Supply (Riverside and Eastgate), both on Square. Every number shown is made up for the example. Your screen shows your real stores.
First, the honest description
What would a validated StoreRounds Square adapter read?
If a production Square adapter passes validation, it would read Square's API on a schedule using a limited token, copy the day's totals for approved locations, and file them with a receipt. No production Square adapter does this today.
What it is
- A read-only reader. Every permission would have to end in _READ, allowing reads and nothing else.
- Cloud to cloud. The intended adapter would read Square's API over an encrypted connection, with nothing installed in the store.
- Scoped to a named list. It would request a short, specific set of read permissions, not full account access.
- A token, not your password. Square would keep the password and issue StoreRounds a revocable token only after pilot approval.
- Yours to switch off. A supported adapter would have to prove that revoking its Square token ends access at once.
What it is not
- A future pilot must not be a writer. Its approved scope list must contain no write permission and must not permit refunds, voids, price changes, or deletion.
- It must not be your password. A pilot would use Square's own authorization screen, not collect a Square password in StoreRounds.
- It must not be full access. The future token would be limited to the named read scopes and would not make StoreRounds an account admin.
- It must not touch card numbers. A validated adapter would request totals and tender types only, never full payment-card data.
- A future pilot must not be surveillance. It would be limited to approved store totals and exceptions, not employee monitoring.
For your IT person
A technician or managed-services provider can review the proposed boundary in the one-page connector security brief. That brief is a pre-production design review, not evidence that a Square adapter is deployed.
The shape of it
How is a future Square connection intended to work?
No StoreRounds Square connection is available today. The proposed cloud path would use Square's standard authorization flow: the owner would approve named read scopes at Square, Square would issue a revocable token, and a validated adapter would use that token to read the approved API data. The diagram is a design target, not a live workflow.
Two facts worth repeating, because they are the whole security story:
- The owner's password would stay with Square. A pilot must never ask for that password inside StoreRounds.
- The token would have to be read-only and revocable. Source-side revocation must stop new adapter reads before the pilot can pass validation.
An honest comparison
Why could Square be simpler than a legacy on-prem POS?
Square is a cloud POS with a documented API, so a future adapter could avoid a store-side installer and database login. That architectural advantage does not mean StoreRounds has completed the adapter or verified Square's current approval screens.
A legacy on-premise POS is a different shape, not a worse one. Its data can sit in a SQL Server or MySQL database on a back-office computer that a cloud service cannot reach, so a future path would need a local connector and an exact read-only database grant. Both routes remain blueprints until a vendor-specific adapter passes a real-store read-back and revocation test.
If your POS is the on-prem kind
If your registers run an older, server-based POS, review the companion on-premise SQL validation blueprint. Its example grants are future-pilot acceptance criteria, not a production installer.
Future pilot validation runbook
What would a Square pilot have to prove?
Do not treat these screens as available today. The four stages below preserve the intended validation runbook for a future adapter. StoreRounds must build the adapter, verify the current Square scopes and screens, and complete a real-store read-back before an owner is asked to follow them.
1
Planned stage: start authorization
Future founder-assisted pilot · timing unproven
- A future pilot would begin only after StoreRounds confirms the adapter and owner are approved for validation.
- The intended portal would expose a Square authorization action inside the approved connection record.
- That action would have to open Square's own authorization domain. No such customer action is available today.
Verify stage 1
Security acceptance criterion: any future password prompt must be hosted on Square's own domain. A pilot owner should close any flow that asks for a Square password on a StoreRounds page.
2
Planned stage: approve named read scopes
Future Square-hosted screen · timing unproven
- An approved pilot owner would use a Square account owner or admin login on Square's domain.
- StoreRounds would have to show and document the exact requested scopes before approval. Every requested permission must be read-only and revalidated against Square's current API.
- Only after that review could the owner authorize Square to issue a limited token to the pilot adapter.
Verify stage 2
Acceptance criterion: a future pilot would have to show the authorized Square business name and a truthful connection state. This expected screen has not been validated in production.
3
Planned stage: map approved locations
Future founder-assisted pilot · timing unproven
Square identifies each store as a location. A future adapter would need to list only the locations returned by the approved token and require a human to map them before any brief could run. Aurora Beauty Supply is fictional example data.
- A pilot owner would confirm the display name for each approved Square location.
- Test, training, closed, and non-selling locations would have to be excluded before validation.
- Set each store's day cutoff (when the sales day ends, for example 11:00 PM) and time zone, so the daily totals line up with your Square Sales Summary.
Verify stage 3
Future verify condition: the approved list must match the owner's active Square locations. The fictional Aurora example shows two. Any missing or extra location would fail validation until the token scope and mapping were reviewed.
4
Required gate: run a real-store read-back
Future pilot only · timing unproven
This would be the release gate. A future pilot would compare one StoreRounds read-back against the owner's Square Sales Summary. Only after a real-store match could the connection be marked verified and a first Morning Flash be scheduled.
The exact grants, in plain terms
Which read scopes would a pilot have to review?
The list below is a proposed scope set, not a statement of current approval or implementation. Before any pilot, StoreRounds must compare it with Square's current API, remove every unnecessary scope, document why each remaining scope is needed, and verify that none permits writes.
| Proposed permission | What it could expose | Intended pilot purpose |
|---|---|---|
| MERCHANT_PROFILE_READ | Your business name and the list of locations. | To find your stores and match them to names you recognize. |
| ORDERS_READ | Completed sales: totals, item counts, tax, and discounts. | The sales numbers in your morning brief. |
| PAYMENTS_READ | How each sale was paid: card, cash, and other tenders. | The cash versus card split, and reconciliation. |
| CASH_DRAWER_READ | Cash drawer shifts: starting cash, paid in and out, expected versus counted. | Cash reconciliation, the drawer against the deposit. |
| INVENTORY_READ | On-hand counts for your items. | Stockout and low-stock flags, when you want them. |
| ITEMS_READ | The catalog names of your items. | So a flag reads a product name, not a bare SKU number. |
StoreRounds does not request these scopes from customers today. This proposed list exists so a pilot owner or IT reviewer can challenge it before any authorization flow is enabled.
# PROPOSED ONLY. No customer authorization flow is live. # Every retained scope must end in _READ and be revalidated before a pilot. MERCHANT_PROFILE_READ # business name and the list of locations ORDERS_READ # completed sales: totals, items, tax, discounts PAYMENTS_READ # how each sale was paid: card, cash, other tenders CASH_DRAWER_READ # cash drawer shifts: expected vs counted cash INVENTORY_READ # on-hand counts, for stockout and low-stock flags ITEMS_READ # item names, so a flag reads a product, not a SKU
The token, in plain terms
In the intended OAuth design, choosing Allow would keep the owner's password at Square and issue StoreRounds a token limited to approved read scopes. A production implementation would have to encrypt that token, renew it only within the same grant, and prove that revocation stops access before the adapter could be supported.
Why this matters
The design goal is a token that can be revoked without changing the owner's Square password or affecting other Square users. A pilot must prove source-side revocation before the adapter can be called supported.
Receipts from minute one
How would a Square pilot prove it read the right location and numbers?
In a future pilot, the owner would check the adapter against a report they already trust. StoreRounds would read one closed sales day for one location, and the owner would compare it with that location's Sales Summary. The adapter would remain unsupported until the numbers reconcile.
Verified Read-back test Aurora Beauty Supply, Riverside · sales day of the example
| Future pilot field | Fictional adapter result | Fictional Square report | Example match |
|---|---|---|---|
| Gross sales | $8,412.70 | $8,412.70 | Yes |
| Transactions | 143 | 143 | Yes |
| Cash tendered | $1,905.00 | $1,905.00 | Yes |
| Card tendered | $6,507.70 | $6,507.70 | Yes |
Fictional validation example only. No customer Square data or production read-back is represented.
To pass the read-back test
- In a founder-assisted pilot, StoreRounds would initiate a read-back for one approved location and closed sales day.
- In Square, open that location's Sales Summary (Reports, then Sales Summary) for the same date.
- Compare gross sales, transaction count, and the cash and card split. They should match to the cent.
- If a future pilot matches, the owner would choose Confirm, numbers reconcile. Only then could the connection be marked verified and a first Morning Flash be scheduled.
If the numbers are close but not exact
A future pilot must stop on any mismatch. Likely investigation points include the day cutoff, gross versus net sales, and the treatment of refunds and comps. No Morning Flash should be scheduled until the owner confirms a clean match against Square's own report.
When a stage will not pass
Which failure modes must a future pilot handle?
These are acceptance scenarios for an unbuilt adapter, not support steps for a connection available today.
The Square sign-in shows the wrong business
Future pilot scenario: Square could show the wrong business if the browser has another active account. The pilot would need a clear abort path, business-identity confirmation, and verified disconnect before retrying.
It says "Connected" but a location is missing
Future pilot scenario: a missing location could reflect owner exclusion, Square deactivation, or insufficient token access. The adapter must show the exact cause and remain unverified until the owner confirms the approved location list.
The read-back numbers are off by a consistent amount
Future pilot scenario: a steady gap could reflect cutoff, time zone, gross-versus-net definitions, refunds, or comps. StoreRounds and the owner would document one definition and repeat the read-back until it matched Square's report to the cent.
StoreRounds says the connection needs to be reauthorized
Future pilot scenario: a revoked or invalid token must fail closed, explain the source-side state, and require a fresh approved authorization. No StoreRounds reconnect control or customer Square token exists today.
Card sales show but cash is missing
Future pilot scenario: missing cash evidence could reflect an unapproved scope or a store that does not use Square's cash-drawer feature. The pilot must distinguish tender totals from drawer reconciliation and must not imply the stronger evidence exists when it does not.
Still stuck
A future supported adapter would need a truthful health record that exposes recent reads, renewals, failures, and the exact unresolved error. This customer-facing health view is an acceptance criterion, not a live Square feature.
Your off switch
How must a future Square pilot prove revocation?
No StoreRounds Square token exists for customers today. Before a pilot adapter can be supported, it must prove two independent stop paths: destroying the credential in StoreRounds and revoking the app at Square. Either path must stop new reads.
Required switch 1: destroy the pilot credential in StoreRounds
The planned disconnect control would have to destroy the working token and prevent the next scheduled read. Its presence and behavior must be verified during the pilot.
Switch 2: revoke from Square
The source-side test would use Square's current connected-apps settings to revoke the pilot authorization. StoreRounds must revalidate Square's current labels and prove that this action kills the token even if a stale credential remains stored.
Use either, or both
A production-ready adapter would document both stop paths and ask the pilot owner to test source-side revocation. This page cannot serve as current menu guidance because the StoreRounds app registration and customer controls are not live.
Verify the revoke
Pass condition for a future pilot: StoreRounds shows no working credential, Square shows no active StoreRounds authorization, and an attempted scheduled read fails closed.
What a future pilot could keep, and must not
In a future pilot, revocation must stop new reads while preserving only the retention the owner approved. Until self-serve export and deletion controls ship, any pilot data request would go through [email protected].
Quick answers
Frequently asked questions
Can StoreRounds change, refund, or delete anything in my Square account?
No production Square adapter is live today. Before a pilot, StoreRounds would have to prove that the requested scopes are read-only and cannot refund, void, edit, or delete anything.
Does StoreRounds get my Square password?
No production adapter is live today. The intended OAuth design would keep your password at Square and give StoreRounds only a revocable token limited to approved read scopes.
Which Square data would a validated pilot adapter read?
No production adapter reads Square data today. A future pilot would request only a named list of read scopes for business locations, completed sales, tender totals, cash drawer shifts, item names, and inventory counts. The exact current scopes would be revalidated before use.
Do I need my IT person to connect Square?
There is no owner connection path to run today. If the adapter passes production validation, the intended browser-only flow may not need IT, but the first pilots will be founder-assisted and should use the one-page security brief for review.
How long does the whole setup take?
The blueprint estimates about 10 minutes after the adapter is built and validated. That estimate is unproven with a real StoreRounds customer and is not a current setup promise.
Why are my Square numbers slightly different from the read-back?
This is a future-pilot troubleshooting note, not a current connection. A mismatch would require checking cutoff, time zone, gross-versus-net definitions, refunds, and comps before the adapter could pass its read-back gate.
How do I turn it off later?
No StoreRounds Square token exists for customers today. A future pilot must prove both StoreRounds-side disconnect and Square-side revocation before the adapter can be called supported.
Founding cohort application
Tell us which POS you run
You can inspect this blueprint without an account. A Square production adapter is not live, payments are closed, and applying does not promise a connection date. If a Square pilot opens, StoreRounds will contact suitable applicants for a founder-assisted validation.
Already invited to the portal? An account does not unlock a Square adapter. Do not enter POS credentials until StoreRounds confirms an approved pilot.