CodePay — Client FAQ

Yes. PIN bypass can be turned on or off through a configuration switch. The setting is centrally managed in PayPilot and applies across supported CodePay terminal models, for both TSYS and Fiserv.

Yes. PayPilot reflects gateway-side transaction status. If a POS-side discrepancy occurs, query the gateway transaction status before retrying a payment to avoid duplicate charges. Incorrect or duplicate transactions can be voided through the terminal or PayPilot when applicable.

Not at this time. CodePay focuses on core payment functionality and does not provide built-in customer-profile storage, loyalty, coupon, or marketing-promotion features in PayPilot or the gateway backend.

CodePay devices do not include built-in, out-of-the-box gift card acceptance. Gift card programs vary by provider and usually require separate integration. Clients may use their own POS app or a third-party app on CodePay devices and integrate through CodePay’s SDK and device capabilities (card reading, QR scanning, transaction interaction) when appropriate.

Yes. Terminals support direct refund initiation from the payment menu. Supported refund types include reference refunds (linked to an original transaction) and no-reference refunds.

Partial refunds are supported on the sale amount. Other fees may not be partially refundable, because fee items are accounted for separately from the sale amount.

On host-based transaction flows (TSYS MultiPASS), transactions are stored on the host in real time, so batch close functions as a close/settlement command rather than a terminal-only upload. Funding timing depends on processor and merchant setup.

Yes. Batch report behavior is configured in PayPilot. A terminal can also print both summary and detail reports during a manual batch close when the corresponding print options are enabled.

Yes. Enable the tip line while leaving the “print tip suggestion” option disabled.

Surcharge is determined by card type and program rules. If credit and debit are set up as separate payment methods, surcharge should apply only to eligible credit transactions. If a merchant wants different pricing for PIN-bypassed debit, a dual-pricing program is usually more appropriate.

No. Surcharge data must be sent to the processor, and surcharge programs must follow applicable processor, card-network, and legal requirements. Note that some processors (e.g., Fiserv) do not support a surcharge program, so merchants who need a compliant surcharge program may have to board on a platform that does. Confirm eligibility and setup with your processor or sponsor bank before enabling.

After batch close, a tip adjustment is generally treated at the processor level as a new sale/additional transaction rather than a change to the already-closed original authorization. On the CodePay gateway side, the original transaction and the adjustment are linked for audit and tracking.

CodePay supports Fiserv and TSYS configurations across the supported terminal models. Supported host/front-end combinations depend on merchant boarding and processor setup.

CodePay is certified on the Fiserv Nashville front end. A merchant can board on the same platform used for Omaha, but must apply for a Nashville account; partners should make sure the front-end network is set to Nashville. The backend does not require special attention (on Fiserv’s side it defaults to North). Settlement generally funds the next business day — for example, a transaction settled at 11 PM or 2 AM is funded the following day. Confirm the exact boarding path with your processor or sponsor bank.

CodePay supports TSYS MultiPASS for gateway-based transaction processing.

Elavon certification is in progress. Confirm current availability with CodePay before committing to deployment timelines.

No. CodePay is not currently certified with Canadian processors. U.S. processor certifications do not automatically carry over to Canadian platforms.

Yes. EBT is supported for both TSYS and Fiserv and is included within existing certification scope, so no separate EBT certification is required. A single PIN encryption key covers both debit and EBT, and Remote Key Injection supports this setup. Final enablement depends on processor, merchant account, and key configuration.

No. In the supported setup, a single PIN encryption key covers both debit and EBT, and Remote Key Injection supports this configuration.

CodePay works with Futurex as its secure key-injection provider. Processor PIN keys are securely delivered to and stored in Futurex’s HSM environment. CodePay then authorizes remote injection for enrolled devices, and the device confirms completion. CodePay never handles raw or plaintext keys.

Key-injection status can be reviewed on the device detail page in the terminal management system (TMS). Batch key injection is also available for bulk deployments.

Traditional PAX deployments are often processor-direct terminal configurations, so the VAR sheet reflects the processor’s terminal setup. CodePay devices are gateway-based: the terminal talks to the CodePay gateway, and the gateway routes the transaction to the processor. Because the transaction flow is different, the VAR sheet parameters differ as well.

Sierra is a traditional terminal-based model — transactions are stored on the device and uploaded to the host in batches at checkout. MultiPASS is a host/gateway-based model in which transactions are stored on the host in real time, and batch close acts primarily as a host-side close command.

Not currently. The payment application supports standard transaction data and does not yet support full Level 2 / Level 3 enhanced commercial-card fields such as invoice-level or line-item data. (This is separate from certification levels: L1 covers hardware, L2 covers EMV, and L3 covers processor integration.)

Supported terminal configurations are centrally managed through PayPilot and TMS. Feature availability may vary by model, firmware, processor, and merchant configuration.

Yes. PIN debit is supported on modern integrated smart terminals without a separate physical PIN pad. PIN entry and encryption are handled through the terminal’s secure hardware (a secure enclave plus an HSM workflow) and the certified EMV payment flow.

CodePay devices currently use Wi-Fi 5 (802.11ac).

Use 2 1/4 x 40 thermal paper, and make sure the roll size and thickness match the paper roll supplied with the device. Incorrect roll dimensions may cause jamming.

Use the recommended roll size and avoid rolls that differ in size or thickness from the included roll (we recommend not sourcing rolls from third-party vendors). If jamming continues, contact support with the terminal model, paper specifications, and photos if available.

The standard warranty is one year from MID activation. Out-of-warranty repairs are available; repair costs vary by case. Detailed repair pricing and the request process are covered in the Warranty & Repair section of the Resource Hub.

Battery life varies by model, screen brightness, wireless settings, and app configuration. Approximate screen-on figures from internal testing:

• T2 — about 9h 11m (config off) / 8h 51m (config on)
• P5 — about 21h 23m (Wi-Fi/GPS on, Bluetooth off)
• P5L — about 9h 33m (config on)
• P5K — about 21h 23m (Wi-Fi/GPS on, Bluetooth off)
• Charge time — about 3 to 3.5 hours (powered off)

Yes. Supported terminals can scan barcodes/QR codes and can display QR codes on-screen for customers to scan. Crypto-wallet QR-code payments are not currently supported as a built-in feature.

Yes, if Google Mobile Services (GMS) are enabled for the device through TMS. Availability may depend on device model and account configuration.

If kiosk mode is triggered by ECR mode, long-press the triangle and square buttons together at the same time to exit.

Developer mode can be pushed to devices through TMS. Provide the relevant device serial number(s) when requesting debugging support.

They serve different purposes. PayPilot is used for merchant setup, payment-app configuration, and transaction settings (initial configuration). TMS is used for device management — remote assistance, pushing apps, pushing updates, and enabling device-level settings.

Not necessarily. Devices are typically assigned to the client’s TMS first. The client then creates a merchant in PayPilot and assigns terminals to that merchant. For PoC deployments, CodePay can help set up a demo merchant before shipment when needed.

CodePay does not separate live and test environments by App ID. If “sandbox” is selected in the merchant account contract, all transactions under that merchant account are test transactions and do not create real charges.

Yes. A C# SDK is available and is based on a webhook-style integration. Webhook communication can also run on a local network, depending on the integration architecture.

There is currently no dedicated iOS SDK. Clients can use WebSocket communication over the local-network IP to connect to and interact with the terminal. Documentation and a Chrome-plugin test tool are available to verify the WebSocket connection.

Yes. A Windows SDK is available for Windows-based integrations.

Yes. Clients can upload their APK to TMS and push the app to the desired terminals (e.g., T2, P5, P5L). The POS app developer or POS partner should provide the APK package and installation/user instructions. If the app is only installed on other devices, uploading it to TMS is not required.

For same-terminal integration, the POS app runs on the CodePay terminal and interacts with the payment application locally. Typical steps: request developer mode for the target device, complete the integration, upload the APK to TMS, push the app to the device, create the payment application in PayPilot, and enable the app for the merchant profile.

No. CodePay is not responsible for third-party POS app development or POS operations. ISOs or merchants should request the APK, installation package, and operating instructions directly from the POS/ISV partner.

For issues involving a POS app or integration workflow, the ISV should generally investigate first, because the ISV owns the app and the integration logic. If the ISV finds a CodePay-related issue, they can escalate to CodePay with technical details. Clear card-processing issues can be raised directly with CodePay support.

SaaS fees start counting from the month after the terminal’s first transaction. For example, if the first transaction happens in February, the SaaS fee starts in March.

Not currently. One device can be bound to one MID. Clients with multi-MID requirements should discuss expected volume and use cases with CodePay so feasibility can be evaluated.

No. CodePay does not currently perform KYC, transaction monitoring, or risk-management functions for merchants. These responsibilities are handled by the ISO, sponsor, or processor, including merchant onboarding and underwriting submissions.

Current white-label customization is limited. Supported options are mainly within the payment app: app-icon customization and UI theme-color customization. Hardware casing customization, boot animation, system-level white labeling, and product renaming (the product name remains “CodePay Register”) are not standard out-of-the-box capabilities and require separate commercial review.

As a general guideline: P5, P5L, P5L PIN Pad, and P5K require a 3,000-unit order minimum; T2 requires a 2,000-unit minimum. Confirm current MOQ and customization feasibility with CodePay sales.

Sub-agent access is managed through role and permission settings in TMS and PayPilot. Clients can create roles to distinguish agent, manager, and sub-agent access levels according to their operating model.

Offline mode is targeted for Q3. Confirm current availability and deployment timing with CodePay before relying on offline transaction functionality.

Not currently. Terminals can scan and display QR codes, but built-in crypto-wallet QR-code payment acceptance is not currently supported.

Not currently. CodePay’s current certification focus is the U.S. market.

Not currently. These features may be evaluated in future phases based on customer demand and business priority.

Not currently as a built-in workflow. If a regulation or customer use case requires post-transaction data fields, CodePay would need detailed requirements to assess product changes.