Merchant Updated April 2026
Security baseline
Operational checklist your team should run through quarterly to keep your APT integration on supported TLS, current certificates, and the right message-level encryption posture.
What it is
A short, opinionated list of the things APT expects you to have in place so your integration stays current as our security posture evolves. None of these are toggles inside APT — they live in your runtime, your CI, and your monitoring.
When to use it
Run the checklist at integration time, then again every quarter and after any major dependency upgrade (Node, Python, OpenSSL, your APT SDK).
Checklist
- TLS 1.2 floor enforced. Your HTTP client's minimum protocol is TLS 1.2 or higher. Verify with
openssl s_clientor a CI gate (see the developer reference). - AEAD-only cipher policy. Disable legacy CBC and RC4 suites in any reverse proxy or service mesh between your app and APT.
- Certificate pinning policy chosen. Either no pinning (recommended), or SPKI-pinning the issuing CA — never the leaf. Subscribe to the
certificate.rotatedwebhook either way. - MLE enabled for regulated payloads. If you handle PAN, full bank numbers, or full Tax IDs through APT, opt in to message-level encryption now rather than waiting for the required date.
- SDK auto-update workflow. Renovate or Dependabot configured against
@aptcommerce/sdkwith auto-merge on patch releases. - Change notifications wired. The five security webhooks (
tls.*,certificate.rotated,mle.*) route to a channel your on-call team monitors. - Advisory list subscription. At least one engineer is subscribed to
[email protected].
Common pitfalls
- Pinning a leaf certificate — it will break on every 60–90 day rotation.
- Caching the MLE
kidbeyond 24 hours. - Running on a runtime whose bundled OpenSSL no longer ships TLS 1.3 — common on EOL Node and Python versions.
- Sending sensitive data over MLE-eligible endpoints in plaintext "just for now" — backfilling MLE later means rotating that data through your systems again.