Pilot estimate
About 10 minutes after adapter validationUnproven estimate for a future founder-assisted pilot.
Connection guide · Clover POS (cloud API)
Clover POS connection validation blueprint
Status: connection blueprint, not a live connector. This page documents the intended scoped-token path. StoreRounds does not yet offer a production Clover adapter.
Clover keeps sales in its cloud. The planned path needs no store-side install: a future adapter would use Clover's sign-in, a scoped read-only token, selected locations, and a read-back against the store's own closed-day report.
Written for the owner, not the developer. The screens below are future-pilot criteria, not an available click-through setup. StoreRounds must revalidate Clover's current permissions and endpoints before any real-store test.
Pilot support
Founder-assistedNo Clover app or self-serve connection is available.
A future pilot would require
Owner plus reviewA Clover account owner and founder approval after the app, scopes, and revocation path are validated.
Running example throughout: a fictional two-store chain, Aurora Beauty Supply (Riverside and Eastgate), both on Clover. Every number shown is made up for the example. Your screen shows your real locations.
First, the honest description
What is the proposed StoreRounds Clover boundary?
No StoreRounds Clover app or production adapter is available today. The intended design would keep the password at Clover, use a revocable token limited to named read scopes and locations, and let a validated adapter read approved daily totals. Every control below must be proven in a founder-assisted pilot.
What it is
- A read-only reader. A future token must carry read permissions only, and the pilot adapter must make no call that changes Clover data.
- Scoped and named. A future pilot would approve exact permissions and locations. A validated adapter would read only the approved sales, tender, and product fields.
- Approved by the owner, on Clover. A pilot must use Clover's own authorization page so the password stays with Clover.
- Yours to switch off. Removing the future app at Clover or destroying its StoreRounds token must stop new reads.
- Self-reporting. A supported adapter would need a truthful health log for reads, renewals, failures, and unresolved errors.
What it is not
- It must be not a writer. A future pilot must prove that the token cannot add, void, refund, or change an order.
- It must be not your password. The intended flow would keep the login at Clover and store only the scoped token.
- It must not read card numbers. A future adapter would request totals and tender type only, not card data.
- It is not a replacement for the Clover Dashboard. Clover's own reporting remains the trusted source during any pilot.
- It must be not surveillance. The intended output is store-level operational exceptions, not employee scoring.
Fair to Clover
Clover is a capable cloud POS with merchant-controlled APIs and its own reporting. The proposed StoreRounds value is an overnight cross-store exception brief above it, but that job has not been proven on a real Clover customer and mixed-POS support is not available.
The shape of it
How is a future StoreRounds Clover adapter intended to connect?
Clover's cloud architecture makes a cloud-to-cloud adapter possible. In the proposed flow, Clover would issue a read-scoped token and a validated pilot adapter would use it over HTTPS. The diagram is a design target, not a live connection.
Two facts worth repeating, because they are the whole security story:
- A future sign-in must happen on Clover, not on StoreRounds, with StoreRounds receiving only the resulting scoped token.
- The future token must carry read permissions only, and the pilot must prove that it cannot write, void, refund, or delete.
One chain, several locations
Clover models locations as merchants. A future pilot would retrieve only approved merchant IDs and require a human mapping before reporting. Aurora Beauty Supply is fictional example data. Mixed-POS support is an intended outcome, not a current capability.
Future pilot validation runbook
What would a Clover pilot have to prove?
Do not treat these screens as available today. The four stages preserve the intended validation runbook. StoreRounds must build the adapter, verify the current Clover app flow, and complete a matching real-store read-back before asking an owner to follow them.
1
Planned stage: start Clover authorization
Future founder-assisted pilot · timing unproven
- A founder would approve the owner and a validated Clover app for a named pilot.
- The future pilot interface would disclose the exact Clover scopes before authorization.
- No customer-facing Clover action exists today. Do not enter Clover credentials from this page.
Sign in to Clover as the owner first
The next step happens on Clover's site, and only the Clover account owner (or an admin with app permissions) can approve an app. If you normally use a device login or an employee login, sign in at clover.com as the account owner in the same browser before you continue, so the approval screen appears instead of a permission error.
Verify stage 1
Acceptance criterion: any future password prompt must be hosted on Clover's own domain and show the exact pilot app and permissions. A StoreRounds-hosted Clover password prompt must always be rejected.
2
Planned stage: approve named read scopes
Future Clover-hosted screen · timing unproven
- An approved pilot owner would verify the Clover business and selected location on Clover's domain.
- Every requested permission would have to be reviewed as read-only, with no write, refund, or void scope.
- Only after review could the owner authorize Clover to issue a scoped token to the pilot adapter.
- Each additional location would require explicit approval and a matching merchant ID.
Before you approve
A future pilot must be rejected if Clover shows any permission that can write, refund, void, or otherwise change data.
Verify stage 2
Acceptance criterion: the future pilot must show the approved Clover business, merchant IDs, exact scopes, and a truthful connected or failed state. This screen is not live today.
3
Planned stage: map approved Clover merchants
Future founder-assisted pilot · timing unproven
A future adapter would return only the merchant IDs authorized by Clover and require a human mapping before reporting. Aurora Beauty Supply is fictional example data.
- Acceptance criterion: a future adapter would return only approved Clover merchants, and the owner would map each one to a real store.
- Test accounts, food trucks, or closed locations would have to be excluded before read-back.
- 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 own Clover closeout.
Verify stage 3
Future verify condition: the approved merchant list must match the owner's active stores. The fictional Aurora example shows two. Any missing or extra merchant would fail validation until authorization and mapping were reviewed.
4
Required gate: run a real-store read-back
Future founder-assisted pilot only
This would be the release gate. A future pilot would compare one StoreRounds read-back with the owner's Clover report. Only a matching real-store result could mark the adapter verified and schedule a first Morning Flash.
Least privilege, in plain sight
Which read-only permissions would a Clover pilot have to review?
The table is a proposed minimum, not a current request. StoreRounds must revalidate Clover's current app model, remove every unnecessary permission, document each retained field, and prove there is no write path before a pilot.
| Proposed Clover permission | What a validated adapter could read | Access |
|---|---|---|
| Merchants | Your locations, their names, currency, and time zones | Read only |
| Orders | Order totals, item counts, and timestamps per location | Read only |
| Payments | Amount and tender type of each payment, for the cash and card split | Read only |
| Inventory | Item and category names, to group what sold | Read only |
| Everything else | Must not be requested by a future pilot. | None |
Why no write permission, ever
The proposed adapter would read and report only. Before a pilot, StoreRounds must verify Clover's current permission model, prove that the issued token cannot write, void, or refund, and document that full card numbers remain outside the requested data boundary.
What you actually handed over
What token model would a future Clover pilot use?
No StoreRounds Clover token exists for customers today. The intended model would use a Clover-issued key representing only the permissions and locations the owner approved. The pilot must prove each property below.
- Clover would issue it after owner authorization. StoreRounds must never create access without that source-side approval or receive the owner's password.
- It would be scoped. The token must reach only reviewed read fields for approved locations.
- Renewal must stay inside the same grant. Any expiry or renewal behavior must be documented and receipted during validation.
- Storage and revocation must be proven. A pilot must encrypt the token and demonstrate that Clover-side removal stops access.
For your developer or IT person (optional): the exact flow and scopes
This archived flow is for design review only. There is no Clover app to authorize and no customer token exchange today.
# ARCHIVED BLUEPRINT. No customer Clover flow is live. # 1. A future pilot would use Clover-hosted approval and request # READ-ONLY permissions only (the *_R scopes below). US host # shown; a validated adapter would use the approved regional host. GET https://www.clover.com/oauth/v2/authorize ?client_id=<STOREROUNDS_APP_ID> &redirect_uri=https://storerounds.com/connect/clover/callback # 2. In the proposed flow, Clover would return a one-time code # for server-side exchange into a scoped token pair. POST https://api.clover.com/oauth/v2/token # -> { access_token, refresh_token, access_token_expiration } # 3. Every read carries the token as a bearer header. A write # call with a read-only token is rejected by Clover (401). GET https://api.clover.com/v3/merchants/<MERCHANT_ID>/orders Authorization: Bearer <ACCESS_TOKEN>
Read-only app permissions requested, using Clover's own names: MERCHANT_R, ORDERS_R, PAYMENTS_R, INVENTORY_R. The cash and card split is read from Payments by tender type. No *_W (write) permission is on the app, so none can be granted. The full permission and endpoint reference is in Clover's developer documentation at docs.clover.com.
Receipts from minute one
How would a Clover pilot prove it read the right store and numbers?
A founder-assisted pilot would select one approved merchant and closed sales day, retrieve the scoped totals, and compare them with the owner's trusted Clover report. The adapter must remain unsupported until those values match and the owner confirms the definitions.
Verified Read-back test Aurora Beauty Supply, Riverside · sales day of the example
| Future pilot field | Fictional adapter result | Fictional Clover 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 |
Numbers are fictional, for the Aurora Beauty Supply example. On your screen these are your store's real totals for the day you check.
To pass the read-back test
- The future pilot would initiate a read-back for one approved merchant and closed date.
- In Clover, open that location's Sales report in the Clover Dashboard, or the register's closeout, 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 refunds or voids. No Morning Flash should run until the owner confirms a clean match.
When a stage will not pass
Which failure modes must a future Clover pilot handle?
These are acceptance and troubleshooting criteria for a future approved pilot, not support instructions for a connection available today.
Clover says I do not have permission to approve the app
Only the Clover account owner, or an admin with app permissions, can install an app. A device login or an employee login cannot.
A future pilot would require an authorized Clover owner or app administrator. StoreRounds must revalidate Clover's current approval roles before asking anyone to authorize.
It connected, but a location is missing
Each Clover location is a separate merchant, and each one is approved on its own. A missing store almost always means that location was not approved yet, or it is marked Do not report.
A future pilot would stop and reconcile the authorized merchant IDs with the intended store list before any reporting could continue.
The connection went from green to "reauthorize needed"
A future pilot must treat a revoked, expired, or owner-changed grant as closed access and stop reads. Any reauthorization would require the owner to review the current scopes again on Clover's domain.
The read-back numbers are off by a consistent amount
A steady gap is a definition difference, not a fault. The three usual causes are the day cutoff hour, gross sales versus net sales, and how refunds and voids are counted.
A future founder-assisted pilot would reconcile cutoff, gross-versus-net, refund, and void definitions against Clover's own report until the values match.
I use Clover in more than one country or region
Clover can use regional hosts. Before any pilot, StoreRounds would have to identify the correct regional authorization and API hosts from Clover's current documentation and validate each requested merchant separately.
A morning brief did not arrive
A supported pilot adapter would need bounded retries, a receipted gap, and an explicit unresolved-error alert. Those behaviors and the customer-facing health record are not production-proven.
Still stuck
A future supported connection would need a truthful health record for reads, renewals, gaps, retries, and unresolved errors. This health view is an acceptance criterion, not a live Clover feature.
Your off switch
How must a future Clover pilot prove revocation?
No StoreRounds Clover token exists for customers today. A future pilot must prove two independent stop paths: destroying the credential in StoreRounds and revoking the app at Clover. Either must stop new reads.
Required switch 1: destroy the pilot credential in StoreRounds
The planned customer control would have to destroy the working token and prevent the next scheduled read. Its presence and behavior must be verified in the pilot.
Required switch 2: revoke the pilot app at Clover
The source-side test would use Clover's current app-management screen to revoke the pilot authorization. StoreRounds must revalidate Clover's current labels and prove that the token then fails closed.
Which switch to use
A supported adapter would document both stop paths and ask the pilot owner to test source-side revocation. No customer StoreRounds app currently appears in Clover.
Verify the revoke
Future pass condition: StoreRounds shows no working credential, Clover shows no active pilot authorization, and an attempted scheduled read fails closed.
What a future pilot could keep, and must not
In a future pilot, revoke must stop new reads. Until self-serve data controls ship, export and deletion requests would go through [email protected].
Quick answers
Frequently asked questions
Status for every answer below: no production Clover adapter is live. These answers describe the intended pilot boundary and must be revalidated before use.
Could a future StoreRounds pilot change Clover data?
It must not. Before a pilot, StoreRounds would have to prove that the requested token is read-only and cannot write, void, refund, or change orders.
Do you see or store my Clover password?
No customer authorization flow is live today. The intended design would keep the Clover password at Clover and give the pilot adapter only a scoped token.
Would a StoreRounds Clover pilot read customers' card numbers?
No production Clover adapter exists today. A future pilot would have to prove that it receives totals and tender type only, never full card numbers.
Does this replace the Clover Dashboard?
No. Clover's native reporting would remain the trusted source during a pilot. StoreRounds' cross-POS follow-up workflow is an intended outcome that has not been proven on a real Clover customer.
Which Clover plans and setups are supported?
None are supported by a production StoreRounds adapter today. A future pilot would have to validate the exact account, region, app permissions, merchant IDs, and current API behavior.
How long does the whole setup take?
The blueprint estimates about 10 minutes after the adapter and app are validated. That estimate is unproven with a real StoreRounds customer and is not a setup promise.
How do I turn it off later?
No customer Clover token exists today. A future pilot must prove both StoreRounds-side credential destruction and Clover-side app revocation before support.
Founding cohort application
Tell us which POS you run
You can inspect this blueprint without an account. A Clover production adapter is not live, payments are closed, and applying does not promise a connection date. If a Clover pilot opens, suitable applicants will be contacted for founder-assisted validation.
A portal account does not unlock a Clover adapter. Do not enter POS credentials until StoreRounds confirms an approved pilot.