[Go to site: main page, start]
Skip to main content
The Security Settings page controls which fields appear on your payment forms and which ones a payer must fill in before a transaction can be submitted. It’s where you tune the balance between collecting enough data to verify a transaction (address verification, CVV, custom merchant fields) and asking for so much that customers abandon checkout. The page is titled Virtual Terminal Fields with the subtitle “Set requirements for address verification settings and card security settings.” Every change you make here applies to the dashboard’s payment forms (KEY, ACH, and other manual-entry flows) for the currently selected merchant account.
From the left sidebar: Settings → Fraud Prevention → Security Settings

​
Layout

The page is organized into three side-by-side columns, each grouping a related set of fields. Every column has an Activate All link in its heading that toggles every checkbox in that column on at once — a quick way to enable an entire group without clicking each box individually. A SUBMIT FILTERS button in the top right saves your changes.

​
Two Toggle Types

Each field row has one or two checkboxes: Some fields show only a Required checkbox — those are core address inputs that are always rendered on the form, so the only setting that matters is whether they’re mandatory. Other fields show both checkboxes, meaning you can choose to hide them entirely (Displayed off), show but allow blank (Displayed on, Required off), or show and require (both on).

​
Billing Information

The cardholder’s billing address fields. These are the inputs Ecrypt forwards to the issuer for AVS verification. Tip: Zipcode + Address are the two AVS workhorses. Even on otherwise lightweight forms, requiring at least the Zipcode catches most stolen-card fraud at the issuer level.

​
Shipping Information

A second address block for the customer’s shipping/delivery address. Useful when goods are being shipped to a different location than the billing address. Whether the shipping block appears on the form at all is controlled by the “Billing address same as shipping” toggle inside the payment forms themselves; this page controls what happens inside the shipping block when it’s shown.

​
Merchant Defined Fields

The custom fields you’ve created in Settings → Terminal Settings → Defined Fields show up here, each with its own Required and Displayed checkboxes. You control whether each merchant-defined field is shown on the payment form (Displayed) and whether the user can submit without filling it in (Required). This is the connection point between the field definitions and the payment forms that actually use them — defining a field doesn’t automatically place it on the form; you also have to check Displayed here.

​
Activate All

Each of the three columns has an Activate All link beside its heading. Clicking it checks every checkbox in that column. Useful when you’re standing up a brand-new merchant and want maximum data capture, or when you’re cloning settings from a stricter merchant. You can then uncheck individual boxes to fine-tune.

​
Save

Click SUBMIT FILTERS in the top right to persist all changes. Until you click Submit, your edits are local to the form and won’t affect live payment pages.

​
Tips & Best Practices

Start strict, then loosen. The cost of asking for too much data is some customers abandoning checkout; the cost of asking for too little is fraud chargebacks and missed AVS matches. For most merchants, Address, City, Zipcode, State, and CVV should all be Required — these give you the strongest verification at the lowest cost in friction. Country, Company, Phone, and Email can usually be left optional (Displayed but not Required) unless you have a business reason to mandate them. The Shipping Information block is only relevant if you actually ship goods. If you’re a service business, restaurant, or anything else where there’s no physical delivery, leave the shipping fields unchecked entirely and the shipping block won’t add any friction to checkout. Conversely, if you ship to a different address than the cardholder’s billing address frequently, requiring Name on the shipping side keeps your fulfillment data clean. Use Merchant Defined Fields when you need to capture business-specific data alongside every transaction — invoice numbers, customer references, table numbers, route IDs — without forcing those onto the standard address fields. Remember that defining a field in Terminal Settings → Defined Fields only puts it in the catalog; you have to check Displayed here to actually surface it on your payment forms. If a custom field never shows up at point of sale, this is the first place to check. The line between Required and Displayed is the most important distinction on this page. Marking something Displayed but not Required is a strong default — it gives the payer the chance to enter the data without blocking checkout if they choose not to. Marking it Required is a hard gate. Marking it neither removes it from the form entirely. Use Required sparingly; over-requiring is the leading driver of cart abandonment on payment forms. Finally, settings here are per-merchant. If you operate multiple merchants and want the same security profile across all of them, you’ll need to configure each merchant individually. Switch merchants in the top-left “Your Merchant Accounts” picker and repeat. There’s no copy-from-merchant shortcut on this page (unlike the Copy Permissions from Another Employee option in User Management).