Skip to main content

​
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

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 and Webhooks. 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.