Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.ecrypt.com/llms.txt

Use this file to discover all available pages before exploring further.

Payment integrations are a common target for fraud. This guide covers the tools ECRYPT provides to help protect your integration, and the steps you should take on your end to reduce exposure.

​
Address Verification (AVS)

AVS checks the billing address submitted with a transaction against the address on file with the card issuer. ECRYPT returns an AVS code on every card transaction so you can evaluate the result and decide how to proceed. 
"avs": {
  "code": "Y",
  "text": "Address and ZIP code match"
}
AVS is a signal, not a guarantee. A passing AVS result does not confirm the cardholder is present or that the transaction is legitimate. Treat it as one factor in a broader risk assessment. A few things to keep in mind:
  • ECRYPT requires ZIP code by default for card-not-present transactions. You can optionally require full billing address instead. Contact your account manager to change this setting.
  • Some issuing banks may decline transactions when no AVS data is provided. Collecting at minimum a ZIP code at checkout reduces this risk.
  • International cards often return a no-match or unavailable result even on legitimate transactions, since many issuers outside the US do not participate in AVS.
  • You can configure ECRYPT to automatically decline transactions that fail AVS checks. Contact your account manager to discuss thresholds.
See Response Codes for the full list of AVS codes and their meanings.

​
CVV Verification

CVV (also referred to as CVC or CVV2) is the 3 or 4 digit security code printed on a card. It is not stored on the magnetic stripe or chip, so its presence confirms the person submitting the transaction has the physical card or at minimum has seen it. ECRYPT returns a CVV response code on every card transaction: 
"cvv": {
  "code": "M",
  "text": "CVV matches"
}
Always collect CVV for card-not-present transactions. A no-match result is a strong fraud signal and in most cases the transaction should not be fulfilled. CVV may not be required for transactions using a stored token, as the card was already verified at the time it was tokenized.

​
Card Testing / Auth Scrub Attacks

Card testing is a fraud technique where an attacker uses your checkout to verify whether stolen card numbers are valid. They typically run a large volume of small transactions or authorizations in quick succession. A spike in declines, particularly on low-dollar amounts, is a common indicator.

​
Use CAPTCHA on public-facing checkout pages

The most effective defense against automated card testing is CAPTCHA on any page that submits a payment. CAPTCHA distinguishes human users from automated scripts and makes bulk testing difficult. Recommendations:
  • Google reCAPTCHA v3 runs invisibly and scores each request without requiring user interaction.
  • Cloudflare Turnstile is a privacy-friendly alternative that also operates without user-visible challenges in most cases.
Implement CAPTCHA at the form submission step, before the tokenization request is made.

​
Additional measures

  • Rate limit by IP address on your server before requests reach ECRYPT. Block or throttle IPs that exceed a reasonable threshold.
  • Require CVV and billing address on all card-not-present transactions. Attackers often omit these fields.
  • Monitor decline rates. An unusual increase in declines, especially for small amounts, warrants investigation.
  • Review your rate limit configuration. ECRYPT’s default rate limit provides a baseline layer of protection. See Rate Limits for details.

​
Duplicate Transaction Protection

ECRYPT automatically blocks duplicate transactions submitted within a 5-minute window. A duplicate is defined as a transaction with the same card, amount, and merchant account within that period. This protects against:
  • Accidental double-charges from users clicking a submit button more than once
  • Retry loops in integrations that do not check for a prior response before resubmitting
  • Automated duplicate submissions from bots or malicious actors
If a duplicate is detected, ECRYPT returns a 409 Conflict response. Your integration should handle this response by checking the status of the original transaction before retrying. If you have a legitimate use case that requires charging the same card the same amount in rapid succession, contact your account manager to discuss options.

​
Rate Limits

ECRYPT enforces a default rate limit of 10 requests per 60 seconds per merchant account. Requests that exceed this threshold return a 429 Too Many Requests response. If your integration requires a higher limit, contact your account manager.

​
Sensitive Data Handling

Never log, store, or transmit raw card data through your own systems. ECRYPT’s tokenization flow is designed so that raw card data never touches your servers. If you are using the hosted iframe or checkout page, this is handled for you automatically. If you collect card data directly, use the /v1/tokens endpoint immediately to exchange raw card data for a token before any further processing. See PCI-DSS Compliance for compliance responsibilities if you plan on handling raw PAN data on your own servers.