Overview
This document describes the e-commerce security controls implemented in the Lunchbox platform, structured to align with FreedomPay's E-Commerce Integration Requirements for Security. It covers guest vs. authenticated checkout flows, account creation and SMS-based phone verification, inline form validation, password requirements, sign-in error handling, and duplicate account prevention.
Guest vs. Account checkout
Lunchbox supports two checkout paths:
Guest users may complete a purchase without creating an account; however, no payment information is saved between sessions. The guest user must manually enter their first name, last name, email address, and payment details on every transaction.
Authenticated users benefit from a persisted, secure session with access to loyalty rewards, saved preferences, and a streamlined checkout experience. The separation of these two flows ensures that account-specific data and payment context are only accessible post-authentication.
Authenticated Checkout  | Guest Checkout
 | 
|
Account Creation & MFA Controls
New users registering for an account go through a multi-step identity verification process before the account is created.
Phone Verification
During registration, the user provides a cell phone number. A 6-digit one-time PIN is sent via SMS to that number for verification.
If the phone number is already associated with an existing account, an error is returned blocking duplicate registration
Email Verification
The user's email address is validated for correct format at the point of entry. If the format is invalid (e.g. missing domain), an error is surfaced immediately: "Please enter your email address." If the email is already registered to an existing account, a corresponding error blocks the duplicate registration
Skipped email entry
 | Invalid email entry 
Registered email entry  |
Pin Code Validation | If an incorrect PIN is entered during the verification step, an error is returned and the user is prompted to re-enter or request a new code. |
Additional Sign-Up Form Validation
The registration form enforces strict inline validation across all required fields before submission is permitted:
Missing required dataFirst name and last name are required fields. If left blank or if a special character is entered (these fields only accept letters and numbers), the form displays "Please enter your first name" / "Please enter your last name" beneath the respective fields. | 
|
Invalid birthday format  | The birthday field requires a complete date in MM/DD/YYYY format. Partial entries (e.g. MM/DD only) trigger the error "Birthday must be in MM/DD/YYYY format," and dates prior to 1900 are explicitly rejected with the message "Please enter a valid date of birth. Birthdays before 1900 are not accepted."
|
Password Requirements
All user passwords must satisfy the following criteria, which are displayed in real time on the registration form with checkmarks as each criterion is met:
If a submitted password does not meet all criteria, the form displays "Please enter a valid password" in red and highlights which requirements remain unmet. The Sign Up button cannot be submitted until all four criteria are satisfied. | 
|
Duplicate Account Prevention
| The registration flow actively prevents duplicate accounts at the point of submission. If a user attempts to register with an email address already associated with an existing account, the system surfaces the error: "An account with this email address already exists. Please sign in to your account or use a different email address." |
Similarly, if the provided phone number is already linked to an existing account, the error "An account with this phone number already exists. Please sign in to your account or use a different phone number" is displayed, blocking registration. | 
|
Sign-in validation
| Upon login, if an incorrect password is entered the user is presented with a clear error message: "Username or password is incorrect," displayed in a pink error banner beneath the password field. This message is intentionally non-specific, it does not confirm whether the email address exists in the system, which prevents account enumeration. |
Secure Request Transmission
Transport Layer Security (TLS) encryption
All communication between the Lunchbox platform and FreedomPay's payment services uses TLS encryption. This protects payment data, customer information, and transaction details from interception during transmission.
Credential Storage
Card account numbers are encrypted at rest in the database using industry-standard encryption. This protects sensitive payment data from unauthorized access if the storage layer is compromised.
IP Logging
The platform logs the IP address of every incoming request, including payment transactions. These logs create an audit trail that supports security investigations, forensic analysis, and dispute resolution. Logs are retained according to the Lunchbox's data retention policies and can be cross-referenced with transaction records.
Request Throttling
Throttling is applied at two levels:
Infrastructure level, where all incoming requests pass through an edge proxy that applies general rate limiting. This protects against high-volume attacks and helps maintain service availability.
Payment level, for which the platform supports configurable limits on payment attempts, is applied at two levels:
Per order: limits the number of payment attempts on a single order
Per customer: limits the number of payment attempts by an individual customer within a defined time window
IMPORTANT NOTE: Payment throttling is not enabled by default. To activate it, the Merchant ( must contact the FreedomPay DevOps team to review and configure appropriate limits based on transaction volume and risk profile.
Blocking Malicious Behavior
The platform uses several controls to detect and block malicious payment activity:
The platform has several built-in controls that work together to catch and stop malicious activity before it causes harm:
Payment throttling: Excessive payment attempts on the same order or from the same customer are automatically blocked when throttling limits are enabled. This covers common attack patterns like card testing and credential stuffing.
Duplicate Transaction Prevention: Rapid repeated submissions of the same payment request are blocked, which prevents duplicate charges and automated abuse.
Address Validation: Every billing and shipping address is checked against a third-party verification service at checkout. If an address cannot be verified, the transaction is rejected.
Proxy-Level Protection: The edge proxy intercepts DDoS attacks, bot traffic, and other suspicious request patterns before they ever reach the application.
Audit and Alerting: IP logs and transaction records are cross-referenced, so security teams can spot patterns like multiple failed attempts from one IP or rapid attempts across different accounts and act on them.