Pinnacle Merchant Payment Gateway

This policy covers Pinnacle Merchant Payment Gateway (“the service”), operated by Pinnacle Merchant Payments LLC of 933 Spring Creek Way, Douglasville, Georgia 30134 (“we”, “us”). It explains what personal data the service handles, why we hold it, who else sees it, how long we keep it, and what you can ask us to do about it.

Two kinds of people are described here, and what we hold about each is different. Staff are the people who sign in to raise invoices. Payers are the people and companies who open a payment link to settle one. A payer never creates an account and never chooses a password.

What we collect about staff

Identity: Name and email address. The email address is also the sign-in name and must be unique.
Password: A one-way bcrypt hash at cost factor 12. The password itself is never written down and cannot be recovered from the hash, by us or by anyone who obtained a copy of the database. If you forget it, it is replaced, not retrieved.
Account state: Which business the account belongs to, whether it is an administrator or ordinary staff, whether the email address has been verified and when, and a counter that lets us invalidate every signed-in session for that account at once, which is what happens when a password is changed.
Preference: Whether the light or dark appearance was chosen. Nothing else about how the service is used is recorded as a preference.
Audit trail: Significant actions taken in the account: what was done, to which record, when, and by whom. This exists so that a disputed change to an invoice or a payment can be traced to an account and a time.
Sign-in attempts: A short-lived counter keyed to the email address and to the network address an attempt came from, used to stop password guessing. It holds a count and an expiry time, not the attempted passwords.

What we collect about payers

Contact details, entered by the business: The name, and where supplied the email address and telephone number, of the person or company being invoiced. A payer does not type these in; the business that raised the invoice does.
The invoice: The invoice number, the amount, the currency, a description of what is being charged, and any expiry date set on the link.
The payment attempt: The amount, the currency, the outcome, the reason for any failure, the network (IP) address the attempt came from, and identifiers issued by Stripe for the payment and, for bank debits, for the mandate authorising it.
A description of the payment method: For a card, the brand and the last four digits. For a bank debit, whether the account is a checking or savings account, and the last four digits of the account number and of the routing number. These are what appear on a statement and are what make a payment identifiable in a dispute.
Refunds: The amount refunded against a payment, if any, and when.

We record alongside each network address whether it was vouched for by a proxy we control or merely supplied in a header the sender can set. An address recorded without that assurance is not treated as evidence of anything, which matters because a chargeback dispute is exactly the moment somebody would otherwise assume it was.

What we never see

We never receive or store full card numbers, security codes, expiry dates, full bank account numbers or full routing numbers. The payment fields on the checkout page belong to Stripe and run in a frame served by Stripe. Those details travel from your browser to Stripe without passing through our servers, and our content security policy is configured so that no script of ours could read them even if one tried.

We also do not operate analytics, advertising, session recording, heat mapping or fingerprinting of any kind, and there are no third-party scripts on the payment page beyond Stripe’s own.

Why we hold it

Each category is held for a stated reason and not used for anything else:

To take a payment you asked to make, and to show the business that it arrived.
To keep accurate financial records, which a business is required by law to keep and to be able to produce.
To detect and prevent fraud, and to answer a chargeback or a claim that a payment was not authorised.
To keep accounts secure, which is what the sign-in counters, the audit trail and the session controls are for.

Where the UK GDPR or EU GDPR applies, the lawful bases are performance of a contract (taking the payment), compliance with a legal obligation (financial records), and our legitimate interests in preventing fraud, securing accounts and keeping a reliable record of what happened. We do not rely on consent for any of it, because none of it is optional to the service.

Who else sees it

We use a small number of service providers, each for one job, each under contract, and none of them is permitted to use the data for their own purposes:

Stripe processes the payments and holds the card and bank details we never see. Stripe is also the source of the fraud checks applied to a payment. See stripe.com/privacy.
Neon hosts the database in which the records described above are stored.
Resend delivers transactional email. It is used only for staff address verification and password resets, so a payer’s details are never sent through it.
Vercel runs the application itself.

We do not sell personal data, and we never have. We do not share it for advertising, we do not trade it, and we do not disclose it to anyone outside the list above except where we are legally required to, for example in response to a valid court order, or where it is necessary to establish or defend a legal claim.

Emails we send

The service sends two emails, both to staff: one to verify an email address when an account is created, and one to reset a forgotten password. There are no newsletters, no marketing and no product announcements, and there is nothing to unsubscribe from.

We send no email to payers at all. If you receive a receipt for a payment, it came from Stripe, and the business that invoiced you may contact you separately by its own means.

Cookies

Reading a page on this site stores nothing on your device. Cookies are written only when a staff member signs in or chooses an appearance, and only to make those work. There are four, none of which is used for tracking:

authjs.session-token, set when a staff member signs in, which keeps them signed in. It holds an encrypted token identifying the account, its role and its business. Kept for 30 days. Without it the service cannot work.
authjs.csrf-token, which protects the sign-in form against forged requests. Deleted when the browser closes.
authjs.callback-url, which records the page to return to after signing in. Deleted when the browser closes.
pmg-theme, set when someone chooses light or dark, so the page does not flash the wrong colours on the next load. Kept for one year.

All four are marked HttpOnly, so no script running in the browser can read them, and all four are restricted to this site with SameSite=Lax. On the live site they are additionally marked Secure, so they are only ever sent over HTTPS.

There is no analytics, advertising, or third-party tracking, and nothing is sold or shared. Because all four are strictly necessary to deliver a service you asked for, no consent banner is shown: there would be nothing to refuse. Stripe may set its own cookies within its payment fields to detect fraud; those are governed by Stripe’s policy, linked above.

Where data is held

Records are stored in a database hosted by Neon in AWS us-east-2, Ohio, United States. The application runs on Vercel. Stripe processes payments on its own infrastructure and may transfer data internationally under its own safeguards.

If you are in the United Kingdom or the European Economic Area, this means your data is transferred outside your region. Those transfers rely on the Standard Contractual Clauses, together with the UK Addendum where the UK GDPR applies. [CONFIRM THE TRANSFER MECHANISM WITH COUNSEL BEFORE PUBLISHING.]

How long we keep it

Payment and invoice records: 7 years: From the date of the payment. This is the ordinary retention period for records needed to satisfy tax and accounting rules and to answer a late dispute. It applies to the invoice, the payment, the last four digits held against it and the audit entries relating to it.
Client contact details: while the business keeps them: A business may delete a client it no longer invoices, subject to the payment records above, which are kept for their own period.
Staff accounts: while the account is active: Deleted or anonymised on request once it is closed, except where an entry is referenced by a financial record that must be kept.
Password reset links: 1 hour: After which the link stops working and must be requested again.
Email verification links: 24 hours: Same.
Sign-in attempt counters: minutes: They exist only for the length of the window they enforce and are then cleared.
Payment provider event records: while needed to prevent double processing: We record the identifier of each Stripe event we have handled so that a repeated delivery does not charge or credit anyone twice.

Security

The measures below are in the software today, not aspirations:

Passwords are stored only as bcrypt hashes at cost factor 12.
Card and bank details are handled entirely by Stripe and never reach our servers.
Every page is served with a content security policy built around a per-request nonce, which blocks injected scripts rather than trusting that none get in.
Sign-in is rate limited per email address and per network address, and a locked-out account is told it is locked out rather than being left guessing.
Changing a password immediately invalidates every session that account had open anywhere.
Every cookie is HttpOnly and SameSite=Lax, and Secure on the live site, so none can be read by a script or sent in cleartext.
Significant actions are recorded in an audit trail, so a change can be traced to an account and a time.

No system is perfectly secure, and we do not claim otherwise. If a breach affects your personal data and is likely to present a risk to you, we will notify you and the relevant regulator within the time limits the law sets, which under the UK and EU GDPR is 72 hours from becoming aware of it.

Your rights

Wherever you are, you may ask us to:

tell you what we hold about you, and give you a copy;
correct anything that is wrong;
delete what we hold, where we are not required to keep it as a financial record;
restrict or object to a particular use;
provide your data in a portable form.

Ask at admin@pinnaclemutualconsulting.com. We will respond within 30 days, and we will not charge you or treat you differently for asking. If your request concerns an invoice raised by a business using this service, we may need to direct part of it to that business, because it decided what to record about you.

If you are in the UK or EEA, these are your rights under the UK GDPR and the EU GDPR, and you may complain to your data protection authority. In the UK that is the Information Commissioner’s Office.

If you are in California or another US state with a comparable law, you have the right to know, to delete, to correct, and to opt out of sale or sharing. There is nothing to opt out of: we do not sell or share personal data, and we have no advertising partners.

Children

The service is for business use and is not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe a child’s data has reached us, write to admin@pinnaclemutualconsulting.com and we will delete it.

Changes to this policy

If this policy changes, the date at the top changes with it. Where a change materially affects how we handle your personal data, we will say so plainly rather than relying on you to notice the date.

Contact

Write to admin@pinnaclemutualconsulting.com, or to Pinnacle Merchant Payments LLC, 933 Spring Creek Way, Douglasville, Georgia 30134. If you are not satisfied with our response, you may complain to your data protection authority.

Privacy policy