KVKK and PCI DSS Compliance: How to Protect B2B Payment and Customer Data

Before you start protecting anything, you need to know what you have. Open a table and write down every data type that circulates in your B2B process: dealer title and tax number, the authorized contact's full name, phone and email, current account balance and activity, billing addresses, payment method details. Separate which of these is personal data under KVKK and which is card data under PCI DSS. The title of Demir Ticaret, a legal entity, is not personal data, but the mobile phone number of Ayşe Yılmaz, that firm's accounting manager, is personal data.

For each data type, answer three questions: where is it stored, who can access it, how long is it kept. In this exercise most businesses find card details sitting in an Excel file, old collection records in unpurged emails, or in WhatsApp threads. Even a partial card number kept in a notebook is a PCI DSS violation.

Once you have built this inventory, your goal is clear: card data must not sit in any environment under your control, and personal data must remain only where the work requires it and only for as long as it requires. The inventory also gives you a starting point for processing personal data properly.

The shortest path to PCI DSS compliance is never storing card data at all. When you collect a dealer payment through a virtual POS or payment link, the card number, expiry date and CVV must never touch your server, they should be entered directly on the page of the PCI DSS certified payment institution. The only thing returned to your system is a token for that transaction and a reference number. Because you do not hold card data in this setup, the bulk of your PCI DSS burden shifts to the payment institution.

In practice it works like this: you send a payment link to Yıldız Bayi for a 18.500 TL collection, the dealer clicks the link, enters the card details on the bank's secure page, the payment is approved, and on your side only the transaction-successful status, the amount and the token appear. For recurring collections, instead of asking for the card again, this token is used, so card data again never sits with you. The same logic applies in direct debit system (DBS) flows, where instead of a card the limit and reconciliation defined on the bank side do the work.

The critical rule here is that you never write the card number into a database, a log file or a support record, even for your own convenience. Never store the CVV under any circumstances, not even at the moment of the transaction; PCI DSS strictly prohibits this. B2BPro's payment link and virtual POS modules are designed to work on tokenization logic, meaning card data is not held on the platform and the collection result is posted to the current account automatically.

3D Secure is the layer where the cardholder verifies the transaction with an extra step on the bank side. The bank sends the person entering the card details an SMS code or an app confirmation, and the transaction is not completed without verification. Because amounts are high in B2B collections, rather than leaving this layer optional, run it as mandatory. In transactions made with 3D Secure, if a claim arises that the card was used fraudulently, liability largely shifts to the card-issuing bank.

Set up the flow like this: after the card is entered on the payment link or virtual POS screen, the system should automatically route to 3D Secure verification; if verification fails the transaction should be rejected and no collection should be posted to the current account. Log failed verification attempts, because failed attempts repeated within a short window may be a sign of a card-testing attack.

When verification is complete, report the transaction result to the dealer and to your own accounting at the same time. When Yıldız Bayi approves the payment, a notification should reach the dealer's phone and the current account balance should update instantly. This both reduces reconciliation errors and makes the process transparent in the dealer's eyes.

One of KVKK's core expectations is that only those who need to access personal data for their work do so. Set this up with role-based authorization. The field sales rep should see only the current account balance and order history of dealers in their own region, and not be able to access a dealer in another region or the full customer list. Accounting should be able to enter the collection and reconciliation screens but not drill into a dealer's card transaction detail, because there should be no card data stored there in the first place.

Give every user their own account, do not share a common username. So that you can trace who performed a transaction, every access and every change must be logged. The answer to the question of who raised Demir Ticaret's credit limit, and when, from 250.000 TL to 400.000 TL must sit in the system. These records serve you both in a KVKK audit and in your own internal controls.

When a staff member leaves or changes role, remove or update their access the same day. Lingering old accounts are the most frequent cause of data breaches. On platforms such as B2BPro, because role definitions, region-based dealer access and transaction history can be set at the module level, these controls run systematically rather than through manual tracking.

KVKK requires you to inform the data subject when you process their personal data. If you are collecting the phone and email of your dealer's authorized contact, you need to present a privacy notice explaining for what purpose this data is processed and with whom it may be shared. While explicit consent is not separately required for data processed within the scope of performing the contract, if you are going to send marketing SMS or email, you are expected to obtain a separate consent for it. Do not confuse these two cases.

Place the consent flow within the natural flow of the work. The privacy notice should be shown when the dealer record is created, and marketing consent should be presented as a separate checkbox that is unchecked by default. A pre-checked box is not considered valid explicit consent under KVKK. Also leave a path for a dealer who wants to withdraw the consent they gave, for example so they can keep receiving collection notifications while stopping marketing communication.

Keep a record of when and with which text the consents were obtained. If an objection comes later, you need to be able to show which text Yıldız Bayi approved on 12 March to give marketing consent. The same traceability is expected for data shared in processes such as offsetting, reconciliation or quotes.

Keeping data indefinitely is contrary to KVKK. Define a retention period for each data type and automate the deletion or anonymization step when the period expires. Commercial and tax records are kept for the legal retention period, but old marketing lists that exceed that period or the unnecessary personal data of a dealer you no longer work with should be purged. Put your retention policy in writing so you can show it in an audit.

Encrypt your backups and your data transfers. When sharing a current account report with a dealer or moving data to accounting, use an access-controlled method instead of an open email attachment. Encrypted communication and encrypted storage keep the data unreadable in the event of a breach, which eases both your risk and the consequences of your notification obligation.

Finally, write a breach response plan. When you suspect a data breach, who will be notified, how the affected records will be identified, and within what time the notification to the Personal Data Protection Board will be made should be decided in advance. KVKK expects you to notify the Board as soon as possible from the moment you learn of the breach, as a rule within 72 hours. Running the plan once as a drill earns back, in advance, the time you would lose during a real incident.