> ## Documentation Index
> Fetch the complete documentation index at: https://docs.droplinked.com/llms.txt
> Use this file to discover all available pages before exploring further.

# PCI posture and card-data handling

> Where cardholder data goes, why Droplinked is not in the card-data path, and how 3-D Secure / SCA is handled.

## The one-sentence answer

**Droplinked forwards captured order information; the provider collects card data and
authorises on their own hosted page or in their own iframe.** Cardholder data — PAN,
expiry, CVV/CVC — is never posted to a Droplinked endpoint, never written to a Droplinked
database, and never present in a Droplinked log.

## How that works, per renderer

| Renderer | Where the card is entered | What Droplinked receives |
| - | - | - |
| `STRIPE_ELEMENTS` | A Stripe-hosted iframe mounted in the checkout page. The card details go from the buyer's browser to Stripe directly. | A `client_secret` reference. No card data. |
| `PAYPAL_REDIRECT` | PayPal's own domain. | An approval/capture reference. |
| `PAYMOB_REDIRECT` | Paymob's hosted payment page. | A transaction reference via signed callback. |
| `MAMOPAY_HOSTED` | MamoPay's hosted link. | A transaction reference via signed callback. |

In every case the money leg is between the buyer and the provider. Droplinked's role is to
create the intent, hold the order, and reconcile the result.

## Defence in depth

Because "we never receive it" is a claim rather than a guarantee, the platform also
refuses to *record* it if it ever arrived:

* Audit-log writes scrub `cardNumber`, `cvv` and `cvc` by field name before persistence.
* PSP error logging runs every payload through a redactor matching
  `secret|key|token|password|signature|authorization|hmac|card|pan|cvv|cvc` before anything
  is written.
* Observability payloads scrub credential headers, including `x-droplinked-api-key`, before
  leaving the process.

## What this means for your SAQ

Droplinked does not make a merchant's PCI determination for them, and nothing on this page
is a compliance opinion. What we can state factually is the integration model, which is
what a QSA will ask for:

* **Redirect providers** (PayPal, Paymob, MamoPay) are a fully outsourced model — the buyer
  transacts on the provider's page.
* **Stripe Elements** is a provider-hosted-iframe model — the payment fields are served by
  Stripe, not by Droplinked or the merchant.

Neither model places Droplinked in the cardholder-data environment. If you need a formal
attestation for a partnership or certification file, ask your Droplinked counterpart rather
than inferring one from this page.

## 3-D Secure, SCA and PSD2

Droplinked does **not** implement 3-D Secure itself. Authentication is performed by the
provider that owns the payment page:

* **Stripe** performs 3DS2 as part of the Payment Intent lifecycle. If a payment requires a
  challenge, Stripe surfaces it in Elements and the intent moves through
  `requires_action` before it can succeed. Your integration does not need to orchestrate
  this — but it must not treat "intent created" as "payment complete".
* **Redirect providers** perform any required authentication on their own hosted page
  before returning the buyer.

**Consequences for an integrator, in both cases:** the order is not paid when the intent is
created, and it is not paid when the buyer returns from a redirect. It is paid when the
provider's signed webhook says so. See [Order lifecycle](/guides/order-lifecycle.md) and
[Webhooks](/guides/payments/webhooks.md).

Where SCA exemptions apply (low-value, recurring, trusted beneficiary), they are requested
and decided by the provider under the merchant's own acquiring relationship. Droplinked
does not assert exemptions on a merchant's behalf.

## Data Droplinked does hold

For each order: line items, quantities, prices, currency, shipping and billing address,
buyer email, the provider's transaction reference, and the computed fee/commission split.
Card data is not in that list.

## Related

* [Payment method coverage](/guides/payments/psp-coverage.md)
* [Webhooks](/guides/payments/webhooks.md)
* [Idempotency and retries](/guides/payments/idempotency-and-retries.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.