Can You Process Refunds and Payments on WhatsApp? A GDPR & PCI Compliance Guide

Yes. You can process payments and refunds on WhatsApp lawfully, provided the conversation never carries raw card data and the money itself moves inside a PCI DSS compliant payment provider that the chat links to. That is the pattern every compliant deployment uses, and the one the card schemes, EU payment law and Meta's own policies point to.

Customers want to settle a premium, receive a claims payout or get a refund in the thread where they filed the claim. Ops, compliance and legal teams at insurers, lenders and travel operators are being asked whether that is permitted under GDPR, PCI DSS, PSD2, POPIA and the francophone African frameworks. This guide answers with the regulations cited, then gives the architecture and a checklist.

This article is informational only and does not constitute legal advice. Confirm your obligations with qualified counsel in each jurisdiction.

What data can and cannot live in a WhatsApp message?

Ordinary personal data can be exchanged in a WhatsApp thread with a lawful basis and appropriate safeguards. Full payment card numbers, full bank account numbers and national ID numbers cannot.

Meta's WhatsApp Business Messaging Policy states that businesses must not share, or ask people to share, full-length payment card numbers, financial account numbers, personal ID card numbers or other sensitive identifiers.

PCI DSS v4.0.1, Requirement 4.2.2, requires that the primary account number (PAN, the long card number) is secured with strong cryptography whenever it is sent via end-user messaging technologies, which the PCI Security Standards Council defines to include email, instant messaging, SMS and chat. Once Meta's Cloud API decrypts a message and forwards it to the business, a PAN is plaintext in every downstream system, and each falls into PCI scope.

Allowed in the thread, with a lawful basis

• Name, phone number, policy or loan reference
• Claim number, amount owed, refund amount
• Last four digits of a card or account, for confirmation
• A hosted payment or refund link

Never in the thread

• Full card number (PAN), CVV, expiry date
• Full bank account number or IBAN in free text
• National ID or passport number
• Photos of cards or ID documents (use a secure upload flow)

Medical detail in health, life or travel claims is a special category under GDPR Article 9 and may not be processed unless an Article 9(2) condition applies; a medical-claims assistant needs that condition and a flow that keeps medical detail out of general transcripts.

GDPR requirements for WhatsApp transactions

Under GDPR (Regulation (EU) 2016/679), a WhatsApp payment or refund flow is lawful if you can name the Article 6 basis, minimise what the thread collects, delete on schedule, and document the processor chain down to Meta.

Lawful basis. For a refund or premium payment the usual basis is Article 6(1)(b), performance of a contract. Collections and statutory record-keeping typically rest on 6(1)(c), legal obligation, or 6(1)(f), legitimate interests. Consent under 6(1)(a) is rarely right for a transaction the customer asked for, because it can be withdrawn. The channel itself does need opt-in under Meta's rules.

Minimisation and retention. Article 5(1)(c) limits personal data to what is necessary, 5(1)(e) limits how long it stays identifiable, and 5(1)(f) requires appropriate security. In chat: ask for a claim reference, not a scanned policy; confirm "card ending 4421", not the full number; delete or pseudonymise transcripts once the purpose is served, subject to your sector regulator's record-keeping periods.

Erasure. Article 17(1) gives the customer a right to erasure without undue delay when the data is no longer necessary. Article 17(3)(b) exempts processing required by a legal obligation, so insurers and lenders keep transaction records for statutory periods while purging the conversational layer. Your architecture must delete a transcript while preserving the ledger entry.

Controller, processor, sub-processor, transfers. The insurer, lender or airline is the controller. The AI vendor is a processor under Article 28, bound by a contract meeting Article 28(3). Meta states in its Cloud API documentation (updated 21 May 2026) that it acts as a data processor on behalf of the business where applicable law recognises the concept. That makes Meta a sub-processor of your vendor, which Article 28(2) allows only with the controller's prior written authorisation, so your DPA must list Meta. Meta publishes WhatsApp Business Data Processing Terms and a European Region Data Transfer Addendum, states it relies on GDPR-compliant mechanisms for EU and UK data moving to the US, offers a Local Storage option, and retains message content for a maximum of 30 days. Record these in your transfer impact assessment.

PCI DSS: why card numbers never touch the chat

Keep WhatsApp out of PCI scope by never letting a card number enter the conversation. Use a hosted payment link and store only a token.

PCI DSS v4.0.1, mandatory in full since 31 March 2025, applies to every system component that stores, processes or transmits cardholder data, so a card number typed into WhatsApp pulls the chat platform, the AI vendor, the transcript store, the CRM and every agent workstation into scope. The PCI SSC's FAQ 1588, published in 2025, confirms that a merchant who fully outsources payment functions to a third-party provider, with the example of sending the customer a link to the provider's website to pay, sits in the simplest validation category, SAQ A, and is not subject to the script-attack eligibility criterion that applies to embedded payment forms. A WhatsApp payment link is exactly that model: the customer taps, enters the card on the payment service provider's (PSP) page, and the PSP returns a token, a reference and a status.

Refunds run in reverse. A compliant refund never asks for the card again: the PSP refund API is called with the original transaction reference, money returns to the original instrument, and the chat receives a confirmation. Payouts to a different account, such as a claims settlement to a beneficiary who never paid you, collect bank details through a secure verified form, not the thread.

One claim vendors will push back on: in Europe and Africa, every "WhatsApp payments" offer is a payment-link handoff. Anyone describing in-chat card capture there is out of policy or misdescribing the product.

What WhatsApp itself allows

Meta permits payment flows on the WhatsApp Business Platform, but native in-chat payments exist only in a few markets. Everywhere else, payments run through links to your own provider.

Native payments. Meta's Payments API lets a business send an order_details message and receive payment status by webhook. In Brazil the customer pays by Pix or a payment link, and Meta's documentation states that WhatsApp does not perform reconciliation: the business reconciles with its PSP using the reference_id. India runs on UPI. Outside these markets, including the EU, the UK and all of Africa as of August 2026, payments run through links or your own checkout.

Encryption and security. Messages between the customer's device and Cloud API use Signal protocol encryption. Cloud API, operated by Meta on the business's behalf, decrypts each message, forwards it to the business over TLS, and manages the keys on the business side. This is not end-to-end encryption between the customer and your servers, which is why Meta's processor status and your DPA matter. Meta states Cloud API holds SOC 2 Type II and ISO 27001 reports, encrypts messages at rest, and does not automatically use business messages to inform ads.

Region-specific rules: Europe, South Africa, francophone Africa

Europe: PSD2 and strong customer authentication. Article 97(1) of PSD2 (Directive (EU) 2015/2366) requires the payment service provider to apply strong customer authentication (SCA) when the payer initiates an electronic payment. For remote payments, Article 97(2) adds dynamic linking: under Article 5 of Commission Delegated Regulation (EU) 2018/389, the payer must be made aware of the amount and payee, the authentication code must be specific to both, and any change invalidates it. A WhatsApp message cannot perform SCA; the two-factor step runs on the PSP's page or in the banking app, and the chat presents amount and payee, then hands off. PSD3 and the Payment Services Regulation were agreed in November 2025 with final texts published on 23 April 2026, applying 18 to 21 months after entry into force. PSD2 remains the operative law today.

South Africa: POPIA. The Protection of Personal Information Act, enforced by the Information Regulator, is fully in force. Section 19 requires appropriate, reasonable technical and organisational security measures with due regard to accepted industry practices, which for card data means PCI DSS. Section 21 requires a written contract with any operator (POPIA's term for processor). Section 72 prohibits transfers outside South Africa unless a listed ground applies (a binding law, corporate rules or agreement giving substantially similar protection, consent, or contractual necessity), so document the ground for your vendor and Meta and prefer in-country hosting. Administrative fines reach R10 million.

Francophone Africa: CIMA and national data laws. The CIMA Code governs insurance across 14 states. Article 13 makes a contract's effectiveness conditional on payment of the premium, which is why premium collection on WhatsApp is a high-value use case. Article 232, as amended in 2014, allows claims to be settled by any means of payment, including mobile money, and Article 231 since the August 2023 reform sets a six-month offer deadline for motor accident claims. Data protection in the zone is national: Senegal's Law 2008-12 (CDP) and Côte d'Ivoire's Law 2013-450 (ARTCI) both require prior declaration of processing to the regulator.

Morocco: Law 09-08. Enforced by the CNDP, Law 09-08 requires prior declaration of personal data processing, with prior authorisation for higher-risk categories including health data. Articles 43 and 44 prohibit transfers to states without adequate protection unless the CNDP authorises them, so a Moroccan deployment needs a CNDP filing naming the vendor and Meta. The CNDP began active enforcement campaigns in 2025.

The compliant architecture: how it is actually done

Compliant vendors separate the conversation layer (personal data, GDPR or POPIA controls) from the payment layer (card data, PCI DSS, inside the payment provider). Nothing crosses from the second into the first except a token, a reference and a status.

1. Identify. The assistant matches the customer to a policy or account reference plus a low-sensitivity check (last four digits or a one-time code).
2. Confirm. It states amount and payee in plain language, satisfying the PSD2 awareness requirement.
3. Hand off. It sends a single-use, expiring hosted payment link from the PSP, or a Pix or UPI order where native payments exist, carrying a reference ID and a non-editable amount.
4. Authenticate and capture. Card entry, 3-D Secure or bank authentication run on the PSP's page. WhatsApp, the AI and the CRM never see the PAN.
5. Return and refund. The PSP posts a webhook with token, reference and status; the assistant confirms in chat. Refunds are triggered by reference against the PSP refund API; payouts to a new account use a secure verified form outside the thread.
6. Log and redact. Every step goes to an append-only log with timestamps and actor IDs, the evidence base for GDPR Article 5(2) accountability, POPIA section 19 and disputes. Inbound messages are scanned for card-number patterns (Luhn-valid 13 to 19 digit strings), IBANs and ID formats before storage; matches are masked and the customer redirected to the secure link.
7. Retain and delete. Transcripts carry a purpose tag and retention clock. Erasure requests delete the conversational record while the PSP ledger persists under Article 17(3)(b).

How FCB.ai applies this pattern. FCB.ai's WhatsApp assistants are designed to support this architecture: payment and refund steps hand off by hosted link to the client's own PCI DSS compliant provider, the platform stores tokens and references rather than card data, inbound card-number patterns are redacted before storage, and each transaction step is audit-logged. Client data is hosted on AWS in Paris (eu-west-3) for European clients and Cape Town (af-south-1) for South African clients, and FCB.ai connects to the WhatsApp Cloud API directly as a Meta Tech Partner, keeping the processor chain to two links. Certification status and audit reports are shared during procurement.

Compliance checklist for WhatsApp payments and refunds

Data in the thread

• No full card, CVV, account or ID numbers requested or accepted in chat.
• Automated redaction of PAN, IBAN and ID patterns before storage or model calls.

GDPR and POPIA

• Lawful basis documented per flow (Article 6; POPIA section 11), plus an Article 9 condition where medical detail can appear.
• DPA with the AI vendor meeting Article 28(3); Meta listed as sub-processor under Article 28(2); POPIA section 21 operator contract.
• Transfer mechanism recorded: Meta's EU or UK addendum, POPIA section 72 ground, or CNDP authorisation.
• Retention schedule that honours Article 17 erasure while preserving ledger records.
• Regulator filings completed where required (CNDP, CDP, ARTCI).

PCI DSS

• Card capture fully outsourced to a PCI DSS compliant PSP via hosted link (SAQ A model, PCI SSC FAQ 1588).
• Only tokens, references and statuses stored in the conversational platform; refunds by reference, no card re-entry.

Payment regulation, Meta policy and operations

• SCA with dynamic linking performed by the PSP or bank for EU remote payments (PSD2 Article 97; RTS Article 5); amount and payee shown in chat before handoff.
• Opt-in recorded; reminder templates approved as utility; human handover available.
• Append-only audit log of every transaction step with actor IDs; breach process covering the vendor, the PSP and Meta.

Putting it into practice

One rule decides what belongs in chat: if a flow needs the customer to give you a card number, it does not belong there; if it needs the customer to confirm, authorise and receive proof, it does. Premium collection, repayments, refund initiation and payout confirmation pass; card-on-file capture and free-text bank-detail collection do not.

FCB.ai's WhatsApp assistants are designed to support the payment-link handoff described above on the Meta Cloud API, with the client's own payment provider holding the card data. If you are evaluating this for a claims, collections or travel refund flow, the fastest way to judge it is a 20-minute walkthrough of the handoff and the audit log it produces, with your DPO in the room. See how the platform works at https://fcb.ai/product, the security overview at https://fcb.ai/security, and what we deploy for lenders at https://fcb.ai/industry/finance/ai-debt-collection and for insurers at https://fcb.ai/industry/insurance/document-ocr.

Related reading: WhatsApp debt collection with conversational AI, at https://fcb.ai/articles/whatsapp-debt-collection-conversational-ai

This article is informational and does not constitute legal advice. FCB.ai deploys conversational AI on WhatsApp for insurers, lenders and travel operators across Africa and francophone Europe. To see how regulated clients use it, visit https://fcb.ai/product

References

1. Meta, "WhatsApp Business Messaging Policy", accessed August 2026. https://www.whatsapp.com/legal/business-policy
2. Meta for Developers, "Cloud API: Data Privacy & Security", updated 21 May 2026. https://developers.facebook.com/documentation/business-messaging/whatsapp/data-privacy-and-security/
3. Meta for Developers, "About the WhatsApp Business Platform", 2026. https://developers.facebook.com/documentation/business-messaging/whatsapp/about-the-platform
4. Meta for Developers, "Payments API, Brazil", updated 14 November 2025. https://developers.facebook.com/documentation/business-messaging/whatsapp/payments/payments-br/overview/
5. PCI Security Standards Council, "PCI DSS v4.0.1: Requirements and Testing Procedures", June 2024. https://www.pcisecuritystandards.org/document_library/
6. PCI Security Standards Council, FAQ 1588, "How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?", 2025. https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/how-does-an-e-commerce-merchant-meet-the-saq-a-eligibility-criteria-for-scripts/
7. PCI Security Standards Council, "FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants", 28 February 2025. https://blog.pcisecuritystandards.org/faq-clarifies-new-saq-a-eligibility-criteria-for-e-commerce-merchants
8. Regulation (EU) 2016/679 (GDPR), Article 5, Principles relating to processing of personal data. https://gdpr-info.eu/art-5-gdpr/
9. Regulation (EU) 2016/679 (GDPR), Article 6, Lawfulness of processing. https://gdpr-info.eu/art-6-gdpr/
10. Regulation (EU) 2016/679 (GDPR), Article 17, Right to erasure. https://gdpr-info.eu/art-17-gdpr/
11. Regulation (EU) 2016/679 (GDPR), Article 28, Processor. https://gdpr-info.eu/art-28-gdpr/
12. European Banking Authority, "EBA clarifies the application of strong customer authentication requirements to digital wallets" (quoting PSD2 Article 97). https://eba.europa.eu/publications-and-media/press-releases/eba-clarifies-application-strong-customer-authentication
13. Commission Delegated Regulation (EU) 2018/389 on strong customer authentication, Article 5, 27 November 2017. https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32018R0389
14. European Banking Authority, Single Rulebook Q&A 2020_5366, dynamic linking for remote electronic payments. https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2020_5366
15. Norton Rose Fulbright, "PSD3 and PSR: From provisional agreement to 2026 readiness", March 2026. https://www.nortonrosefulbright.com/en/knowledge/publications/cedd39c6/psd3-and-psr-from-provisional-agreement-to-2026-readiness
16. Protection of Personal Information Act 4 of 2013 (South Africa), section 19, Security measures on integrity and confidentiality. https://popia.co.za/section-19-security-measures-on-integrity-and-confidentiality-of-personal-information/
17. CNDP (Maroc), "Formalités", accessed August 2026. https://www.cndp.ma/formalites/
18. Conférence Interafricaine des Marchés d'Assurances, Code des assurances, consolidated text. http://www.droit-afrique.com/uploads/CIMA-Code-assurances.pdf
19. 221 Assurances, "Assurance : la CIMA s'engage à lever les obstacles à la rapidité du paiement des sinistres", 22 May 2025. https://www.221assurances.com/2025/05/22/assurance-la-cima-sengage-a-lever-les-obstacles-a-la-rapidite-du-paiement-des-sinistres/