PayI Payment Security Policy

1. How Payments Work

PayI integrates with Peach Payments as its sole payment gateway provider. When an MSP's client makes a payment, the following process occurs:

1. The client is presented with a secure payment form hosted by Peach Payments. This form is rendered within an iframe or redirect, card details never touch PayI's servers.
2. The client enters their card details directly into the Peach Payments secure form. All card data is encrypted end-to-end within Peach's PCI DSS certified infrastructure.
3. Peach Payments processes the transaction with the card network and issuing bank, including 3D Secure authentication where applicable.
4. Peach Payments notifies PayI of the outcome via a signed webhook. Before that delivery is journaled, PayI strips every cardholder, customer and address field Peach echoes back, along with any field whose name contains a token or a URL.
5. PayI records the gateway's transaction reference, result code and payment brand, updates the invoice status, and notifies the MSP and client of the payment outcome.

Because the card is entered on Peach Payments' own hosted page and no card credential is returned to or kept by PayI, PayI operates entirely outside the scope of PCI DSS cardholder data storage requirements: no sensitive authentication data and no full card numbers are ever present in our systems.

2. What PayI Stores

To reconcile a payment against an invoice and to chase an unpaid one, PayI stores the following non-sensitive payment information — and nothing that could be used to charge a card:

None of these data elements, individually or combined, can be used to reconstruct a full card number or make a payment outside of the Peach Payments merchant relationship.

3. What PayI Does NOT Store

• Full card number (PAN): The complete 16-digit (or longer) card number is never sent to, received by, or stored on PayI servers. It is entered exclusively on Peach Payments' PCI-certified secure form.
• CVV/CVC security code: The 3- or 4-digit security code on the card is entered directly on Peach Payments' form and is never transmitted to PayI. Per PCI DSS rules, CVV data must never be stored after authorisation, even by the payment processor.
• Card PIN: PINs are never collected in online transactions. They are used only at physical point-of-sale terminals and are completely outside PayI's scope.
• Bank account numbers: PayI does not support direct bank transfers or debit orders that would require storage of bank account numbers. All payments flow through the Peach Payments card processing infrastructure.
• Bank routing numbers: Not applicable to PayI's payment model and never collected.
• 3D Secure authentication data: One-time passwords, biometric confirmations, and other 3D Secure credentials are handled entirely within the bank's authentication domain.

4. Peach Payments: Our PCI DSS Certified Payment Processor

Peach Payments is a South African payment service provider that holds PCI DSS Level 1 certification, the highest level of security certification in the payment card industry. This certification means:

• Peach Payments undergoes annual on-site audits by a Qualified Security Assessor (QSA)
• Their infrastructure meets all 12 PCI DSS requirement categories covering network security, access control, monitoring, and vulnerability management
• They process over 1 million transactions annually, qualifying them for Level 1 (the most stringent tier)
• Card data is encrypted using industry-standard protocols within their secure environment

By delegating all card handling to Peach Payments, PayI ensures that sensitive financial data is managed by a specialist provider with the highest level of security certification. PayI itself does not need to be PCI DSS certified for cardholder data storage because no cardholder data is ever present in our systems.

5. Data Isolation

Payment records are strictly scoped to the MSP that owns them:

• Application-level isolation: Every API request is authenticated and authorised against the requesting MSP's identity. Application-level checks are designed to prevent an MSP from accessing another MSP's data through any documented API path.
• Database-level isolation: All payment-related database queries include the MSP identifier as a mandatory filter. There is no query path that can return payment data across MSP boundaries.
• Encryption at rest: Stored secrets and third-party credentials — webhook signing secrets, and the OAuth tokens for an accounting integration an MSP has connected — are encrypted with AES-256-GCM under a platform master key, with the key version recorded in the ciphertext so keys can be rotated. Invoice and client records are not separately encrypted at the application layer.
• Audit trail: All access to payment data is logged in a tamper-evident audit trail. Any anomalous access patterns are flagged for review.

6. Incident Response

In the unlikely event of a data breach affecting PayI systems, the exposure is bounded by what PayI actually holds — and PayI holds no means of charging anyone:

• There is no payment credential to steal: PayI stores no card number, no CVV, no card token, no expiry date and no bank account details. An attacker holding a complete copy of the PayI database could not initiate a payment against any client.
• What a breach could expose: invoice and payment history, client contact details, and the gateway's own transaction references. That is personal information, and it is covered by the commitments below.

Our Incident Response Commitments

In the event of a security incident involving payment data, Synchplus Consulting (Pty) Ltd commits to:

• Notify affected MSPs as soon as reasonably possible after becoming aware of the incident, in accordance with section 22 of the Protection of Personal Information Act, 2013 (POPIA)
• Notify the Information Regulator of South Africa and affected data subjects where section 22 of POPIA or other applicable law requires
• Provide a detailed incident report including scope, impact, and remediation steps
• Implement corrective measures to prevent recurrence

7. Contact

For questions about payment security, to report a suspected security vulnerability, or to discuss our security practices, contact our security team:

For general privacy enquiries, contact our POPIA Information Officer at privacy@kapardyn.com.

See also: PayI Terms of Use | PayI Privacy Policy