Use the Customer-Present Cloud device workflow

Register and persist the GUID

Enable Encrypted Devices on the account. Register the currently displayed rotating code with POST /api/v2/devices/register using Bearer authentication. registrationCode is required and deviceNickname is optional. Store poiDeviceId with your merchant/location mapping; an expired code must be refreshed from the terminal.

Separate API generations

This source workflow uses v2 device management and the Classic payment route. The portal also has v5 Device REST references. Do not combine their field casing or response formats. Match the family used by your existing integration before copying a request.

Observe asynchronous completion

Store the returned async reference with the order and poll the documented status route. An accepted request is not an approved payment. Keep uncertain attempts available for reconciliation; do not replace an attempt merely because the browser or cashier screen timed out.

Configure prompts without conflicts

poi_require_keyed and poi_enable_keyed cannot both be true. Quick-tip amounts and percentages are mutually exclusive and require poi_prompt_tip. Signature prompting cannot override card-required PIN. Device entry may replace a ZIP supplied in the request. Keep the total and prompt configuration consistent.

Check standalone input capability

Standalone signature, yes/no and menu actions have device-specific support. RBA iPP320/iSC250 do not support these standalone inputs; unsupported targets can return unsupported_device. Signature support is narrower than yes/no/menu support. A captured signature is not a payment authorization.

Test enrollment before checkout

The Virtual PIN Pad uses T00001 for registration success and T00002 for failure. Its test amount behavior is not a physical-device certification. When the account reports no devices, verify the account key before re-registering; when a code is invalid, use the current device display.