Privacy Policy

Payshen is a payment orchestration and provider-connectivity platform used by merchants and by payment service providers (PSPs). Which hat we wear depends on the data:

• We are the controller for account data, sign-in records, security logs and sales enquiries - the data we need to run the platform itself.
• We are a processor for the data you put into your workspace: payment metadata, business records, and uploaded documents. We process it on your instructions to provide the Service.
• PSPs are separate controllers for anything you submit to them through the platform. Once an application or a document is shared with a PSP, that PSP handles it under its own privacy policy and its own regulatory duties.

• Account and access data - your email address, your name if you give one, which workspaces you belong to and your role in each, the time you last signed in, and session records. Sign-in is by magic link; session tokens are stored hashed, never in the clear.
• Sales enquiries - name, email, company and message when you use the contact form on our home page.
• Business records - legal entity name, registered country and address, company registration number, VAT id, website, business vertical, regulator, licence status and number, and your expected transaction profile (volumes, average value, payment methods).
• Onboarding documents - PDF, PNG or JPEG files up to 10 MB that you upload to your document vault: certificates of incorporation, articles of association, UBO declarations, director identification, proof of address, licences, bank letters, processing statements and similar. These often contain personal data about directors and beneficial owners who are not users of the Service. You upload them and remain responsible for having a lawful basis to do so.
• Payment metadata - amount, currency, country, payment method, your own reference, the provider chosen, the routing decision and why it was made, attempt outcomes, decline category and the raw provider code, fees, and refund and dispute totals.
• Provider credentials and webhook secrets - the API keys you enter for your own payment providers and the signing secrets for your webhook endpoints. These are encrypted with AES-256-GCM before they are written to the database and are never displayed again after creation.
• Security and audit data - an audit trail of significant actions recording the acting user’s email, the action, its target, and the IP address it came from; rate-limiting counters keyed by IP address; and delivery logs for outbound webhooks.

No Payshen screen, API or SDK collects a card number. There are no card fields anywhere in the product. The hosted payment page we redirect to in build mode is a clearly labelled sandbox with outcome buttons, deliberately with no card inputs at all.

The redirect flow exists precisely so that card entry happens on your payment provider’s own hosted page, under that provider’s PCI DSS scope. As a result Payshen does not store, process or transmit primary account numbers, expiry dates, security codes or magnetic-stripe data, and holds no such data to lose.

We use data to operate and secure the Service: authenticating you, routing payment traffic across your own providers, producing your analytics and reconciliation views, transmitting the applications and documents you send to PSPs, maintaining an audit trail, billing you, and preventing abuse.

Aggregated provider performance signals (approval rates, fees, latency) train the routing engine. That model works on payment and provider attributes, never on identified individuals.

We do not sell data and we do not use it for advertising.

The routing engine automatically chooses which of your providers should attempt a payment, and may retry a decline on a backup provider. That is a decision about a transaction and a provider, not a profile of a person.

Decisions on PSP applications - approval, rejection, requests for more information, pricing - are made by the PSP’s own staff in their portal. Payshen does not underwrite applicants and does not decide them automatically.

• PSPs you apply to - the answers on your application form, and only the documents you explicitly attach to that application. Each share is per document and per application, and you can revoke it from your document vault. Nothing is shared with a PSP you have not applied to.
• Your own payment providers - the transaction details needed to authorise a payment, sent using the credentials you configured, under your own agreement with that provider.

We rely on the following sub-processors to run the Service:

We give workspace owners at least 30 days' notice before a new sub-processor starts processing, and you may object - the mechanism is in clause 5.2 of the DPA.

We disclose data where we are legally required to. How we handle a demand from a public authority - including notifying you, challenging it, and disclosing the minimum - is set out in clause 7.4 of the DPA, and it applies to your data whether or not you have signed anything.

We set two cookies, both strictly necessary. There are no analytics, advertising or third-party tracking cookies, which is why you are not asked for cookie consent.

A daily job enforces these windows automatically. Anything not listed is kept for the life of the workspace.

Deleting a workspace deletes its data - members, payments, providers, business records, documents and audit entries - permanently and by cascade. Export anything you need first.

• Provider credentials, webhook signing secrets and every uploaded file are encrypted with AES-256-GCM by the application before they reach any storage backend, so the storage backend never holds plaintext.
• Documents are only ever served through routes that check your authorisation first; the underlying storage URL is unguessable and yields ciphertext even if it leaks.
• Session tokens and API keys are stored as hashes. API keys are shown once, at creation.
• Workspace isolation is enforced in the data layer, not only in the interface, and sensitive actions are written to an audit trail.
• Because we hold no cardholder data, the most sensitive category in payments is simply out of scope here.

Wherever you are, you may ask us to access, correct, export or delete your personal data, or object to a particular use, and we will not charge you or treat you worse for asking. Your local law may give you more than this; section 11 says what.

Much of it needs no request at all. Workspace owners can export payment data as CSV, read the full audit trail, manage documents and revoke shares, and delete the workspace and everything in it from the dashboard, at any time.

Where we are only the processor - personal data inside a document a merchant uploaded, for example - we will not act on your request ourselves. We will pass it without undue delay to the organisation that is the controller, and tell you we have done so.

Send requests through the contact form. We respond within 30 days, and will tell you if a law that applies to you gives us less time. You can also complain to your supervisory authority - section 11 names them by region.

We are established in Wyoming, USA, so personal data you send us is transferred to the United States. That is the whole of the transfer question and it is better stated plainly than buried.

For customers and data subjects in the EEA, the UK and Switzerland, these transfers are covered by the Standard Contractual Clauses, the UK International Data Transfer Addendum and the Swiss variations, all completed in Annex D of the DPA. Because we are the importer rather than the exporter, those clauses are offered by us and already filled in - you do not have to send us yours.

We are not currently self-certified to the EU-U.S. Data Privacy Framework or its UK extension. This page will say so until we are.

Which law applies to you depends on where you are, not on where we are. These are the regimes we operate under and what each one adds.

EEA, including Cyprus and Malta. You have the rights of access, rectification, erasure, restriction, portability and objection, and the right not to be subject to a decision based solely on automated processing producing legal or similarly significant effects - which we do not carry out. Our lawful bases are contract for providing the Service, legitimate interests for security, fraud prevention and product improvement, and legal obligation where one applies; we do not rely on consent except for optional communications, which you can withdraw at any time. We have no EEA establishment, so no lead authority applies and you may complain to your own - the Office of the Commissioner for Personal Data Protection in Cyprus, or the Information and Data Protection Commissioner in Malta, for example. We have not yet designated an Article 27 representative in the Union; one will be appointed before we market to EEA customers and named here.

United Kingdom. The same rights apply under UK GDPR and the Data Protection Act 2018, and you may complain to the Information Commissioner's Office. A UK Article 27 representative has not yet been designated and will be named here when it is.

Switzerland. The revised Federal Act on Data Protection applies and the Federal Data Protection and Information Commissioner is the competent authority.

United States. Under the CCPA as amended by the CPRA, and the comprehensive laws of the other states listed above, you may know, access, delete, correct and obtain a portable copy, and opt out of sale, sharing and targeted advertising. There is nothing to opt out of: we do not sell or share personal information, we have not done so in the preceding twelve months, and we run no advertising or cross-context behavioural advertising. We do not use or disclose sensitive personal information for purposes beyond those permitted without a right to limit. We do not offer financial incentives and we will not discriminate against you for exercising a right. You may use an authorised agent, and we will verify the request against data we already hold. Where we act for a business customer we are a service provider or processor and will route your request to them.

Canada. PIPEDA applies, and in Quebec the Act as amended by Law 25 - including the right to be informed of processing outside Quebec, which is section 10 of this page, the right to data portability, and the right not to be subject to a decision based exclusively on automated processing. We make no such decisions about people. Complaints go to the Office of the Privacy Commissioner of Canada or, in Quebec, the Commission d'accès à l'information.

Middle East. For the United Arab Emirates the Federal Personal Data Protection Law applies; in the DIFC, Data Protection Law No. 5 of 2020; in the ADGM, the Data Protection Regulations 2021; in Saudi Arabia, the Personal Data Protection Law; in Bahrain, the PDPL. Each gives rights of access, correction and deletion, and each has its own regulator - the UAE Data Office, the DIFC Commissioner of Data Protection, the ADGM Office of Data Protection, and the Saudi Data and AI Authority. We will execute any additional transfer documentation these regimes require, at no charge.

If we change how we handle data we will update this page and its date, and tell workspace owners about material changes.

For privacy requests or questions, use the contact form on our home page.