E-Commerce Data Recovery: Trendyol, Hepsiburada, Magento, WooCommerce Scenarios and PCI-DSS

An e-commerce operation depends on dozens of critical services running continuously, one after another. The order table, the product catalog, the cart session, the payment processor integration, the shipping API, the invoice queue, the customer profile, the coupon engine, the seller dashboard; all of these live inside a single database schema or in tightly coupled microservices. When a single InnoDB page is corrupted, the entire site freezes on a campaign day. When a single line of Magecart code is injected into one JavaScript file, card data leaks for weeks. In this article we walk through the cases that the Turkish e-commerce ecosystem encounters most often, platform-specific recovery approaches, the boundaries of PCI-DSS and KVKK compliance, and coordination with local payment providers, all with concrete steps.

To see the bigger picture first, you may want to start with our main guide: Data recovery guide 2026 Turkey. After that, we will return to the e-commerce specifics.

Turkey's e-commerce layers: marketplace, own store, hybrid

Brands running e-commerce in Turkey generally operate across three layers. The first layer is the marketplace seller dashboards; platforms such as Trendyol, Hepsiburada, n11, Amazon TR and Çiçeksepeti give the seller an account to manage their own orders, products and messages. The second layer is the brand's own e-commerce site; here you find Magento (Adobe Commerce), WooCommerce (WordPress), Shopify, PrestaShop, OpenCart, and locally widespread platforms such as IdeaSoft, Ticimax and T-Soft. The third layer is the ERP, accounting and e-invoice side; e-Archive and e-Invoice queues are run through the GİB e-Document system (https://ebelge.gib.gov.tr).

When building a data recovery plan, these three layers must be considered separately. The reason is that marketplace data (orders, customer addresses, messages) is often not held by the brand itself; it is pulled in via API and mirrored into the brand's own database. When a database failure occurs, it is possible to pull the data again from the marketplace, but there are limits on quotas, pagination and how far back you can go. When the brand loses its own store database, on the other hand, customer history is gone for good if there is no backup.

Typical case 1: MySQL corruption on Black Friday

The period when demand for e-commerce data recovery peaks is the late-November campaign days. At the busiest traffic of the season, a single SSD's firmware locks up, the RAID controller cannot flush its cache, and a page in the middle of the MySQL InnoDB tablespace becomes corrupted. As the site tries to stay online, messages like Got error 1712 from storage engine or Page corruption start hitting the log.

The first thing to do at this point is to close the site to write traffic. The read_only=1 flag is set, or the load balancer freezes order POST requests. Then, before anything else, a bit-for-bit image is taken from the live disk; no InnoDB repair command should be attempted before a read-only copy is made with ddrescue, because innodb_force_recovery=6 can irreversibly discard bad pages.

Once the image is taken, three parallel paths are tried: first, a logical export with mysqldump that skips the corrupted pages; second, a point-in-time replay from the binary logs (mysql-bin.*) on top of the last clean backup; third, a table-by-table extract with Percona Toolkit. If there is also a problem at the RAID level, the process takes longer; you can read our article that covers the topic in depth, RAID 5 failure: recovery process and cost.

The critical question during seasonal traffic is "how many hours of loss can we accept?" If the RPO (Recovery Point Objective) target is 5 minutes, binary log shipping or MySQL group replication is mandatory. An e-commerce site running on a single daily mysqldump, when it crashes on Black Friday afternoon, is forced to roll back to the morning's backup, and thousands of orders cannot be re-entered.

Typical case 2: Magecart skimming and card data leakage

The attack type that has caused the most damage to Magento and WooCommerce stores for years is the family of JavaScript skimmers known as Magecart. The attacker injects a line of card-stealing JS into the store's front end or into a third-party analytics, chat, coupon or A/B test script. The customer types in their card number, and before the form is submitted, the skimmer sends the characters to a remote server. CISA has issued warnings about Magecart variants and pointed to it as a concrete example of supply chain risk (https://www.cisa.gov).

In a Magecart case, "data recovery" carries two meanings. The first is returning the store to its clean state; the second is forensically determining the scope of the leaked card data. The process is as follows:

1. A readable image of the web server and the database is taken.
2. CSP (Content Security Policy) violation logs, CDN access logs, and the core_config_data and cms_block tables are scanned. For how CSP and SRI should be configured, the MDN documentation (https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) is a good starting point.
3. The controls under OWASP Top 10 (https://owasp.org/www-project-top-ten/) A08 "Software and Data Integrity Failures" are applied; in particular, SRI hashes are checked for third-party script integrity.
4. The affected card range (BIN, first and last 4 digits, time window) is determined.
5. The acquiring bank and the payment processor are notified.

Here, PCI-DSS compliance plays a critical role. The PCI-DSS v4.0 standard published by the PCI Security Standards Council (https://www.pcisecuritystandards.org) imposes strict controls for every environment where card data is stored. In Turkey, the vast majority of brands use BDDK-licensed payment institutions such as iyzico, PayTR, Param, MOKA, Sipay and Birleşik Ödeme. These processors tokenize the card in their own PCI-DSS Level 1 environments; only a token remains in the seller's database. A correctly configured iframe or hosted payment page significantly narrows the seller's PCI scope.

However, Magecart also hits stores that say "I don't hold the card, iyzico does." That is because the skimmer reads the value from the DOM before the form is submitted, so even if it is never written to the seller's database, it still ends up in the attacker's hands. For this reason, keeping the CSP script-src directive strict, pinning third-party scripts with an SRI hash, and serving the checkout page under a separate sub-domain with minimal third-party content are defensive layers that PCI-DSS v4.0 itself recommends.

Typical case 3: WooCommerce plugin XSS and database poisoning

In the WooCommerce world, the most frequently encountered vulnerabilities are plugin-driven stored XSS and SQL injection cases. An unlicensed or out-of-date "product filter", "review slider" or "import/export" plugin can give an attacker the ability to write to the wp_options, wp_users and wp_woocommerce_order_items tables.

In this type of case, the order of data recovery is as follows. First the site is put into maintenance mode, then the wp-content/uploads, wp-content/plugins, wp-content/mu-plugins, .htaccess and wp-config.php files are scanned from a separate copy. PHP webshell signatures (eval(base64_decode, assert($_REQUEST, gzinflate(str_rot13) are searched for. In the database, the siteurl, home and active_plugins values inside wp_options and any new admin accounts in the wp_users table are queried.

There are two approaches to database cleanup: roll back to the last clean backup before the date the breach began and re-sync the orders in between either manually or from the marketplace API, or clean the existing database row by row and delete the injected records. Which one is appropriate is decided based on the duration of the breach and the order volume.

Typical case 4: Ransomware and e-commerce hosting

Ransomware now targets not only Windows file servers but also Linux-based web hosting. Cases where the ESXi virtualization layer was breached have been seen in Turkey as well. If the hosting provider's shared backup has been encrypted, the situation is serious.

We have a comprehensive guide on what to do in the first 24 hours: The first 24 hours after ransomware: emergency response. For e-commerce specifically, the following additional steps are needed:

1. The hosting provider is contacted immediately, and log retention is extended so that logs are not deleted in rotation. Apache/Nginx access logs, FTP/SSH session logs, and the MySQL general log if present are copied.
2. The payment processor is alerted. Depending on the scale of the incident, iyzico, PayTR, Param and MOKA can temporarily halt webhook traffic.
3. If there is suspicion that the attacker accessed the marketplace (Trendyol, Hepsiburada) seller dashboard, the API keys are rotated.
4. Under KVKK Article 12, a breach notification is filed with the Board within 72 hours. For the detailed process and form, see our article KVKK data breach notification: the 72-hour form.

Typical case 5: Accidental DELETE and "is there a binary log?"

Human error is a classic. A developer means to write DELETE FROM orders WHERE status='draft' on the production database, forgets the WHERE clause, and the entire order table is wiped. In this case, the chance of recovery depends entirely on the backup and binary log configuration.

In MySQL, if log_bin=ON and binlog_format=ROW, the last full backup is restored, then a replay is done with mysqlbinlog up to one second before the delete command, and the deleted rows return. If PostgreSQL is in use, a WAL archive is essential; point-in-time recovery is performed with pgBackRest or Barman. In MongoDB, if the oplog window is wide enough, a similar rewind is possible.

At this point, the following rule emerges: in e-commerce databases, the backup strategy should not end at 3-2-1. The 3-2-1 rule (three copies, two different media, one off-site) is the basic baseline, but modern e-commerce requires additional layers. Immutable backups (object-locked S3 or a WORM disk), point-in-time recovery (binary log/WAL archive), and restore drills (at least monthly, a real RTO test). If you have a backup but have never tested a restore, you effectively have no backup.

KVKK scope: B2C customer + B2B seller

An e-commerce operation processes both B2C (consumer customer) and B2B (marketplace sellers, dropshipping suppliers, shipping company staff) data. The special categories of data under KVKK Article 6 (health, religion, biometrics) are generally not present in e-commerce databases; however, name, address, phone, email, IP, order date, and national ID number (for e-invoicing) are processed under Article 5.

When a breach occurs, KVKK (https://www.kvkk.gov.tr) requires notification within 72 hours at the latest. The notification form asks for the start date of the breach, the number of affected records, the data categories, and the measures taken. In long-running leaks such as Magecart, determining the number of records is critical; the forensic team must be able to provide the number of cards leaked on a daily basis.

An interesting point: B2B seller data also falls under KVKK when it belongs to a real person. When an individual seller's (sole proprietorship) marketplace account is hacked and their personal information leaks, the seller is also considered a victim of the breach and falls within the notification scope.

Social engineering and seller dashboard takeover

Another attack type that has become widespread in Turkey in recent years is taking over marketplace seller dashboards through phishing. The attacker sends emails that appear to come from Trendyol or Hepsiburada, with subjects like "return approval", "campaign enrollment" or "account verification". The seller clicks the link, submits their credentials, and the attacker logs into the dashboard, adds their own IBAN, and redirects pending payments to themselves.

We have an article that explains in detail how to distinguish such emails: How to spot a phishing email 2026. We recommend that e-commerce teams forward this content to all of their staff.

Coordination with the payment processor

After a breach, it is essential to work in coordination with iyzico, PayTR, Param or MOKA. The general flow is as follows. Once the breach is confirmed, a written notification is sent to the processor, with the affected transaction range (date, order ID, BIN range) provided. The processor initiates compromised account management program (CAMP) processes with the card schemes (Visa, Mastercard, Troy). The affected cards are reported to their banks, and the banks make decisions on a per-customer basis.

In this process, the seller's PCI-DSS SAQ (Self-Assessment Questionnaire) type becomes important. Sellers using an iframe or redirect architecture are generally within the scope of SAQ A and never touch card data. Sellers who relay the card number directly from the server fall under SAQ D and bear a much heavier obligation. A Magecart case burns even a SAQ A seller, because the vulnerability does not occur on the server but in the DOM in the browser; for this reason PCI-DSS v4.0 tightened its "script integrity" clauses.

Pulling marketplace data back

If the brand's own store database is completely lost and there is no backup, the last resort is the marketplace APIs. The Trendyol Marketplace API pulls recent orders by date range with pagination, and the Hepsiburada seller API is similar. The constraints here are:

• A retroactive date limit (usually 14-30 days; for anything older, a manual support request is needed).
• An hourly request quota (if the rate limit is exceeded, the account is temporarily restricted).
• Message history and return reasons cannot always be exported from the API; if needed, screen recordings of the seller dashboard are required.
• The customer's real email and phone are masked as required by KVKK; for communication, the marketplace's own messaging channel is used.

Backup architecture: beyond 3-2-1

The backup design we recommend for an e-commerce business consists of these layers.

1. Hourly incremental database backups (XtraBackup, pgBackRest or MongoDB Ops Manager) on a local NAS.
2. A daily full backup to S3-compatible object storage in a different data center, with object lock (WORM) enabled.
3. Continuous binary log/WAL shipping (for point-in-time recovery).
4. A weekly snapshot to cold media (LTO tape or an immutable copy in a different cloud region).
5. A monthly restore drill; a backup file is taken, restored to a separate server, and the row count of the order table is verified.

For Magento, additionally, var/, pub/media/, app/etc/env.php and customized theme/module folders should be backed up at a separate frequency. For WooCommerce, if wp-content/uploads and the database are not in sync, the images end up mismatched with the orders.

Encryption and key management

PCI-DSS requires that card data be encrypted "at rest"; in Turkey, sellers using a processor have already delegated this obligation to the processor. However, application-level encryption is also recommended for personal data (within KVKK scope). Encrypting the database files at the disk level (LUKS, dm-crypt) provides one layer, and column-level encryption (especially for national ID and phone) adds a second layer. The keys should be kept in a KMS separate from the database (AWS KMS, HashiCorp Vault, or in Turkey the TÜBİTAK BİLGEM key systems).

A caution: full disk encryption only solves the "server is stolen" scenario. If ransomware gets in while the server is running, the encryption is already transparently unlocked, so the attacker reaches the data as well. For this reason, it is not a sufficient defense on its own.

Local laboratory support in Turkey

Magento database corruption, post-hack cleanup for WooCommerce, MySQL InnoDB tablespace repair, bringing a store back up after ransomware; all of these jobs should be done in a controlled environment, with equipment of known origin and a team that understands PCI-DSS.

Our laboratory at Hacettepe Teknokent in Ankara runs a process tailored to e-commerce operations. The order database, product media, invoice queue and payment webhook logs are handled together; coordination with the payment processor, KVKK notification and forensic reporting are offered as a single package. For customers operating from Istanbul or another city, you can read our article where we explain the logistics flow in detail, Istanbul data recovery via Ankara Hacettepe Teknokent.

When the site goes down in the middle of the season or in the dead of night, our 24/7 emergency response line is open: +90 536 662 38 09. The first call is a free preliminary technical assessment; our team maps out the entire picture, from the database type to the payment processor integration, and then gives a clear timeline and price. After that, the decision is the business's to make.

E-commerce data recovery is not just about bringing files back. As the store reopens, you simultaneously need to manage payment processor compliance, KVKK notification, marketplace synchronization, customer communication and the SEO impact. Working with the right team both shortens the timeline and limits the long-term commercial impact of the breach.