Payment Gateway and SRED Device Integration for Oracle Forms Applications
Summary
We build payment gateway and secure keypad integrations for hospitality, timeshare, and property management systems running on Oracle Forms. These systems still take payments where the card is not present and an employee keys the number by hand. Pairing a hardware encryption keypad with a tokenizing gateway means digits are encrypted inside the device at the moment of entry, the application forwards ciphertext it cannot read, and what comes back is a token and a masked value safe to store.
The Challenge
Done naively, a keyed account number passes through the business application, the database, and every log along the way, which drags the entire estate into the sensitive data environment. Removing that path is the point of the work, and it has to be done inside a legacy stack rather than around it, because the forms already carry the guest and folio relationships the payment attaches to.
Several failure modes follow. Reaching a USB device from a browser-deployed form is not direct, since the form itself runs remotely. Outbound calls from the database tier depend on a trust store holding the gateway certificate chain, and rotation there is a recurring operational task rather than one-time setup, and a common cause of sudden payment failures. Timeouts are the dangerous case: an authorization that succeeded at the gateway but timed out at the application will be retried and can double charge. Account numbers also leak easily into trace files, database audit output, and error messages, most often by logging a full request payload during debugging.
The Solution
The device and the gateway
SRED stands for Secure Reading and Exchange of Data, a hardware security property covering how a device captures, encrypts, and releases account data. A keypad-style SRED device attaches over USB at the workstation, encrypts each entry under a key derived per transaction rather than a static shared secret, and emits ciphertext. Decryption happens inside the gateway hardware security module, never in the merchant environment. A cloud payment gateway performs the authorization and returns a token referencing the stored card. The business application therefore never handles a readable account number, and the token is portable within the gateway, so a card on file survives without local retention.
Working inside Oracle Forms and PL/SQL
The work is layered. Existing forms are analyzed together with the packages, procedures, and tables behind them, so transaction, token, and audit columns are added to structures that already carry the guest and folio relationships. Interface changes go through Form Builder, keeping the payment panel consistent with the screens operators already use. A workstation bridge, historically a signed Java component or a local helper process, reaches the USB endpoint. Outbound calls to the gateway go over HTTPS from the database tier using the standard HTTP packages, with the trust store configured for the gateway certificate chain and rotated before expiry.
Transaction flow and stored state
The operator enters the amount and the billing postal code, which travels with the authorization for address verification. The keyed card data goes device to gateway. The response carries an approval or decline, a masked account number for display, and a token. The application stores the token against the guest record along with the postal code, the authorization identifier, and the response codes needed for dispute handling. Card-check or zero-value verification transactions follow the same path.
How we build it
We map the existing form and database objects first, then define the transaction record and token lifecycle before touching interface code. Gateway integration is developed against a sandbox with full decline, timeout, and partial-approval coverage, since production only shows the happy path until it does not. Every request carries an idempotency reference and a reversal path. Regression testing covers the untouched flows in the same forms, because shared packages carry blast radius, and settlement is reconciled against gateway batch reports rather than internal totals alone.
What This Delivers
Operators keep the screens they know while readable card data stops existing anywhere in the estate, which narrows compliance scope to the device and the gateway. Cards on file support later charges, refunds, and recurring billing, and disputes can be worked from stored authorization identifiers and response codes.
Technologies and Tools
Oracle Forms and Form Builder, PL/SQL packages on an Oracle database, standard database HTTP packages over HTTPS with a managed trust store, a USB SRED encryption keypad, a signed workstation bridge component, and a cloud tokenizing gateway with hardware security module decryption.