Search Results encrypt_card_info

Overview

IBY_CREDITCARD_PKG is the core PL/SQL package within the Oracle Payments (IBY) module responsible for the validation, encryption, masking, storage, and retrieval of payment instrument data—primarily credit cards and purchase cards—within Oracle E-Business Suite Release 12.1.1 and 12.2.2. The package encapsulates the security-sensitive operations that govern how cardholder data is persisted in the EBS database and how it is presented back to end users. It centralizes the business rules for instrument type classification (CREDITCARD and PURCHASECARD), card number masking and unmasking, and the ciphering and deciphering of cardholder names and card numbers. Because Oracle Payments must comply with payment card industry data protection expectations, IBY_CREDITCARD_PKG serves as the controlled gateway through which card data is written to and read from the underlying tables. It is registered under the APPS schema and is classified as a general API object.

Key Procedures and Functions

The package exposes 28 documented procedures and functions. The user search term "decrypt_instruments" corresponds to DECRYPT_INSTRUMENTS, one of the bulk data-handling routines. A representative selection from the documented metadata follows:

• GET_MASK_SETTINGS — Retrieves the configured credit card mask setting and unmask length from the system security options.
• MASK_CARD_NUMBER — Generates a masked representation of a card number based on the configured mask settings.
• GET_CC_ENCRYPT_MODE — Returns the encryption mode currently configured for credit card data.
• OTHER_CC_ATTRIBS_ENCRYPTED — Indicates whether ancillary card attributes are subject to encryption.
• GET_BILLING_SITE — Resolves the billing site associated with a card or party.
• ENCRYPT_CHNAME / DECRYPT_CHNAME — Encrypt and decrypt the cardholder name.
• CREATE_CARD / UPDATE_CARD — Create and update card instrument records after validation.
• CHECK_CARD_VALIDITY — Validates a card number, expiry, issuer, and instrument type, returning one of the package error constants (for example, INVALID_CARD_NUMBER or INVALID_CARD_EXPIRY).
• QUERY_CARD — Retrieves stored card information for a given instrument.
• UNCIPHER_CCNUMBER / UNCIPHER_CCNUMBER_UI_WRP — Decipher a stored card number, with a UI wrapper variant intended for form-driven access.
• DECRYPT_INSTRUMENTS / ENCRYPT_INSTRUMENTS / REMASK_INSTRUMENTS — Bulk operations that decrypt, encrypt, or re-mask sets of stored instruments, typically during migration, key rotation, or display processing.
• COMPRESS_CC_NUMBER / UNCOMPRESS_CC_NUMBER / GET_COMPRESSED_LEN — Compress and decompress card numbers and report the compressed length, supporting storage and index constraints.
• ENCRYPT_CARD_INFO — Encrypts card information prior to persistence.

Tables Accessed

The package reads and writes the primary instrument tables IBY_CREDITCARD, IBY_CREDITCARD_H, and IBY_CREDITCARD_H_S, along with IBY_INSTR_S for instrument-level data and IBY_IRF_RISKY_INSTR for risk-flagged instruments. Issuer information is drawn from IBY_CREDITCARD_ISSUERS_B and IBY_CC_ISSUER_RANGES, which support card issuer and range validation. Security configuration and ciphering are governed by IBY_SYS_SECURITY_OPTIONS, IBY_SECURITY_SEGMENTS, and IBY_SYS_SECURITY_SUBKEYS. Cardholder and billing data are resolved through the TCA tables HZ_PARTIES, HZ_LOCATIONS, HZ_PARTY_SITES, and HZ_PARTY_SITE_USES. DUAL supports scalar operations.

Usage Notes

IBY_CREDITCARD_PKG is invoked by Oracle Payments forms and flows during card entry, validation, and display, as well as by concurrent programs performing bulk encryption, decryption, or re-masking of instruments. It is referenced by 14 other packages, indicating broad internal reuse across the Payments and related modules. Custom code should call the documented public procedures rather than manipulating the underlying card tables directly, because masking, compression, and cipher operations must remain consistent with the configured security options and subkeys. The decryption routines in particular are sensitive and should be restricted to contexts where the caller holds the appropriate responsibility, since they expose clear-text card numbers.