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. Upon successful payment, Peach Payments returns a payment token and limited card metadata (last 4 digits, card brand, expiry) to PayI via a secure webhook.
5. PayI stores the token and metadata, updates the invoice status, and notifies the MSP and client of the payment outcome.

This tokenisation model ensures that PayI operates entirely outside the scope of PCI DSS cardholder data storage requirements, as no sensitive authentication data or full card numbers are ever present in our systems.

2. What PayI Stores

For the purpose of enabling recurring payments, dunning, and payment display, PayI stores the following non-sensitive payment information:

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. Token Security

Payment tokens stored by PayI are protected by multiple layers of security:

• Encryption at rest: All payment tokens are encrypted using AES-256-GCM (Advanced Encryption Standard, 256-bit key, Galois/Counter Mode) before being written to the database. AES-256-GCM provides both confidentiality and integrity protection.
• Per-MSP derived keys: Each MSP's payment tokens are encrypted with a unique derived encryption key. This means that even in a theoretical database breach, tokens from one MSP cannot be decrypted using another MSP's key.
• Key hierarchy: MSP-specific keys are derived from a platform master key using HKDF (HMAC-based Key Derivation Function). The master key is stored separately from the application database and is never logged or exposed.
• Access control: Token data is accessible only through authenticated API calls from the MSP that owns the data. Role-based access control ensures that only authorised users (MSP Admin, MSP Finance) can view or use payment tokens.

6. Recurring Payments and Dunning

When an MSP enables auto-pay for a client or the dunning engine triggers a payment attempt for an overdue invoice, the following secure process occurs:

1. PayI's billing engine determines that a charge is due (either scheduled auto-pay or dunning escalation).
2. The encrypted payment token for the client's stored payment method is retrieved from the database and decrypted in memory using the MSP's derived key.
3. PayI sends only the token (not any card details) along with the charge amount and reference to the Peach Payments API via a TLS-encrypted connection.
4. Peach Payments resolves the token to the stored card details within their PCI-certified environment and processes the charge with the card network.
5. Peach Payments returns the transaction result (success/failure, reference ID) to PayI. No card details are included in the response.
6. PayI updates the invoice and payment records, and notifies the MSP and client of the outcome.

At no point during this process does PayI have access to, process, or transmit the actual card number, CVV, or any other sensitive authentication data. The token is the only credential used, and it is only meaningful within the context of the Peach Payments merchant relationship.

7. Data Isolation

Payment tokens and all associated payment data 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 isolation: As described in Section 5, each MSP's tokens are encrypted with a unique derived key. If database-level isolation is bypassed by an unanticipated defect or compromise, the encrypted data is not usable without the correct MSP-specific derived key.
• Audit trail: All access to payment data is logged in a tamper-evident audit trail. Any anomalous access patterns are flagged for review.

8. Incident Response

In the unlikely event of a data breach affecting PayI systems, it is important to understand the limited exposure risk of our tokenisation model:

• Tokens alone are useless: Payment tokens are bound to the specific Peach Payments merchant account. An attacker who obtained tokens could not use them to make charges through any other merchant account, payment processor, or system.
• No card reconstruction: There is no mathematical or computational method to derive the original card number from a payment token. Tokens are opaque references, not encrypted card numbers.
• Encrypted at rest: Even in a database breach scenario, tokens are stored in encrypted form (AES-256-GCM). Without the MSP-specific derived encryption key, the token values cannot be extracted.
• Token revocation: In the event of a confirmed breach, Peach Payments can immediately revoke all affected tokens, rendering them permanently unusable.

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
• Work with Peach Payments to revoke any potentially compromised tokens
• Provide a detailed incident report including scope, impact, and remediation steps
• Implement corrective measures to prevent recurrence

9. 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