Search Results g_rc_unknown_card

Overview

IBY_FNDCPT_SETUP_PUB is the public setup API for Oracle Payments (formerly Funds Capture) within Oracle E-Business Suite. It provides the programmatic interface through which the application and external integrations define and retrieve the configuration of payers, payment channels, payment instruments, and their assignments. In the Oracle Payments architecture, "setup" data is the master configuration that governs how funds capture is performed for a given payer: which payment channels are enabled, which instruments a payer may use, which channel is the default, and what instrument-level attributes are required, optional, or disabled.

The package exposes a set of constants, record types, and 25 documented procedures and functions. The constants (for example G_CHNNL_ATTRIB_USE_OPTIONAL, G_CHNNL_ATTRIB_USE_REQUIRED, G_CHNNL_ATTRIB_USE_DISABLED, and the result codes such as G_RC_INVALID_CHNNL and G_RC_UNKNOWN_CARD) standardize the values passed to and returned from its APIs. The declared record types — notably PayerAttributes_rec_type, PmtChannel_rec_type, PmtChannelAssignment_rec_type, and PmtChannel_AttribUses_rec_type — define the structure of setup data exchanged with callers, including bank charge bearer, direct debit bank instruction, and the use flags for instrument attributes such as PO number and billing address.

Key Procedures and Functions

The documented routines cluster into four functional areas:

• Payer attributes: GET_PAYER_ATTRIBUTES returns the attributes record for a payer, and SET_PAYER_ATTRIBUTES writes them. GET_TRXN_PAYER_ATTRIBUTES retrieves payer attributes in a transaction context.
• Payment channels: GET_PAYMENT_CHANNEL_ATTRIBS returns the attribute-use configuration for a channel; SET_PAYER_DEFAULT_PMT_CHANNEL and GET_PAYER_DEFAULT_PMT_CHANNEL manage the payer's default channel; GET_TRXN_APPL_PMT_CHANNELS returns the channels available to a transaction's application.
• Instrument assignments: SET_PAYER_INSTR_ASSIGNMENT, GET_PAYER_INSTR_ASSIGNMENTS, GET_PAYER_ALL_INSTRUMENTS, and GET_TRXN_APPL_INSTR_ASSIGN control which payment instruments a payer may use and under what conditions.
• Credit cards and identifiers: CREATE_CARD, UPDATE_CARD, GET_CARD, CARD_EXISTS, PROCESS_CREDIT_CARD, and the wrapper variants CREATE_CARD_WRAPPER and UPDATE_CARD_WRAPPER manage stored card records. GET_PAYER_ID and GET_HASH resolve payer identity and generate hash values used for secure card handling.

Tables Accessed

The package operates against the IBY, HZ, and related setup tables through APPS synonyms:

• Payer and party data: IBY_EXTERNAL_PAYERS_ALL and IBY_EXTERNAL_PAYERS_ALL_S hold external payer definitions; HZ_PARTIES and HZ_PARTY_SITE_USES supply party and site information; IBY_ACCOUNT_OWNERS links accounts to owners.
• Instruments and cards: IBY_CREDITCARD stores card records; IBY_PMT_INSTR_USES_ALL and IBY_PMT_INSTR_USES_ALL_S hold instrument usage assignments; IBY_EXT_BANK_ACCOUNTS and IBY_EXT_PARTY_PMT_MTHDS (with its _S table) hold external bank account and payment method data.
• Channels and attributes: IBY_FNDCPT_PMT_CHNNLS_B defines payment channels; IBY_PMT_MTHD_ATTRIB_APPL defines the application of payment method attributes.
• Debit authorizations: IBY_DEBIT_AUTHORIZATIONS and IBY_DEBIT_AUTHORIZATIONS_S store direct debit authorization records.

Usage Notes

IBY_FNDCPT_SETUP_PUB is a public (PUB) API intended for supported extension points. It is invoked from Oracle Payments setup forms, funds capture processing flows, and concurrent programs that maintain payer and instrument configuration. The package is also referenced by approximately 35 other packages in the E-Business Suite, confirming its role as a foundational setup layer rather than an end-user-facing routine.

Custom code that needs to read or maintain payer setup should call these APIs instead of writing directly to the underlying IBY tables, so that validation rules — reflected in the result-code constants such as INVALID_INSTRUMENT or INVALID_PMT_CHANNEL — and record structures are respected. Callers must handle the returned status codes and supply the declared record types. Because the package manipulates secure card data and hash values, it should be invoked only within supported funds capture contexts, and direct table updates should be avoided.