Updated May, 2025

Executive Summary

Corporate credit cards offer flexibility to organizations.  Corporate credit card integration makes expense tracking straightforward and reduces delays in the recording and reconciliation process.  By automating credit card integration, you reduce errors since users are not manually entering all the credit card charges.  The focus here is on the setup and ongoing maintenance of the credit card integration with various card providers.


Over the last couple of years, Oracle has increased the controls to support higher levels of PCI compliance.  By following the guidance in this document, your credit card integration should be a seamless process with minimal manual intervention. 

Process Overview

Definitions

You will find the following terminology throughout this blog post.  

  • PCI DSS Compliance – The Payment Card Industry Data Security Standard (PCI DSS) is a set of standards intended to ensure all companies that process, store, or transmit credit card information maintain a secure environment.
  • Luhn algorithm – also known as the modulus 10 or mod 10 algorithm. This is a simple checksum formula used to validate a variety of identification numbers, such as credit card numbers, IMEI numbers, Canadian Social Insurance Numbers.
  • Masking – Credit card masking applies a built-in format to mask credit card numbers. Replacing some digits of credit card numbers with ‘x’, MasterCard banks typically mask digits 7-12. Oracle accepts any combination of digits 2-12 masked if the last 4 digits are visible.
  • Tokenization – Credit card tokenization is the process of completely removing sensitive data from a company’s internal network by replacing it with a randomly generated, unique placeholder called a token.

Process Overview

Below is an overview of the corporate card transaction files processing in Cloud ERP, Expenses.
 

A picture containing diagram of the corporate card transaction file processing in Oracle Cloud Expenses.
Figure 1: An overview of the corporate card transaction files processing in Oracle Expenses

 

Before you start configuring your application for processing credit card transaction data, work with your corporate card issuer to establish connectivity and determine the format and frequency for file delivery.  Additional details about establishing connectivity can be found here.


At a high level, the application loads the transaction file and validates the transactions.  All valid transactions are created as expense items and available to employees for expense reporting.  Invalid transactions should be reviewed by corporate card administrators.
The remainder of this document focuses on the file format(s) supported by Oracle Expenses.

Expenses: Card Providers and Formats

Card Providers

Oracle offers integration with American Express, Diner’s Club, MasterCard, and Visa.

Supported Formats

Each customer must confirm their bank (corporate card issuer) can generate one of the file formats listed below.

  • American Express – GL1025 Tokenized Transaction File or Encrypted file
  • Diner’s Club – Standard Data File format with Tokens 
  • MasterCard Common Data Format – version 3.0 (CDF3.0) Masked (also called Encrypted)
  • Visa – VCF4 format with Tokens

For additional details on these formats, please see How You Upload Corporate Card Transactions with Encrypted Card Numbers

Note: You can no longer load files that contain full card numbers. Card numbers must be masked or tokenized according to the format above.

Card Provider Systems

Each card provider listed above uses a standard system to produce the files.  We strongly recommend discussing this with your bank, especially for MasterCard and Visa.

  • American Express has a system called ‘Tokenizer’.  This will generate tokens that are PCI Compliant and do not pass a Luhn algorithm check.  When an Oracle customer reaches out to American Express (electronictransmissionsteam@aexp.com), American Express is very familiar with the integration to Oracle Cloud ERP Expenses.
  • MasterCard uses ‘SmartData’.  Oracle recommends discussing your requirements with a SmartData knowledgeable resource at your bank.  Ask for masked data in the CDF3 file.  Masking means replacing certain digits of the card number with the letter ‘x’.  Typically, SmartData/MasterCard will mask digits 7-12 with x. 
  • Visa uses VIDS (Visa Intellilink Data Solution).  When your banks use VIDS, we have no issues.  When local banks try and use their own solution, we often do not see the same success.  VIDS will produce a token that is a 1, followed by 11 random digits, followed by the last 4 digits of the card.

Unique Requirements 

Mastercard  

For Oracle to successfully process a CDF3 MasterCard transaction file, the employee id (person_num) must be in the file in a very specific location – in the AccountInformation_4300 tag.  This employee_id and the AccountInformation_4300 tag, must be in the file for every transaction.  Many banks configure this to provide that data for hierarchy changes only, but Oracle requires it for every transaction.  The following image shows the correct boxes to be checked in SmartData:

A screenshot of a configuration window in SmartData showing the correct checkboxes recommended for integration with Cloud Expenses.
Figure 2: Image of SmartData Configuration

Note – this screen shot may be out of date at any time, however, share these details with your local bank.


Why does Oracle need the employee id on every transaction? 

Expenses takes the masked card value using a combination of eight digits of the employee id, plus the last 4 visible digits of the card.  This twelve-digit value is what we in Oracle call an internal token.

Visa

For Visa, when customer banks are using VIDS (Visa IntelliLink Data Solutions), the bank will configure a screen like this:

A screenshot of a configuration window in VIDS showing the correct checkboxes recommended for integration with Cloud Expenses.
Figure 3: Visa configuration screen

Text

Description automatically generated

Note – this screen shot may be out of date at any time, however, the details should be able to be communicated to a local bank.

Configuring a Card program

When configuring a card program in Expenses, you should select the following card treatments:


A table showing the card treatments recommended for importing credit card expenses

Expenses: Corporate Card Integration

Do not use UCM for Credit Card Files

Expenses does not allow card issuers to directly push corporate card transaction files to your Cloud environment.  This means you are not allowed to load files to Oracle Cloud ERP using UCM.  This is a PCI compliance violation. 

To receive files directly from Visa, MasterCard, or Diner’s Club, you must set up an HTTPS or SFTP server at your site or with a third party. Alternatively, you can set up an HTTPS or SFTP server at the card issuer’s site so it can host your corporate card transaction files.

Configure HTTPS or SFTP for Credit Card Files

The upload to Expenses works on a ‘pull’ model.  For Diner’s Club, MasterCard and Visa, you must set up either an HTTPS server or an SFTP server and configure the corporate card program.  You need to define an ‘outbox’ directory on the server and secure it with a username and password.  

Next, you configure the Upload Parameters section on the Corporate Card Programs page. Include the server configured above as well as the folder where the files will be dropped.  Then you will include the file name.  Oracle uses a static name for your file.  You are responsible to move or rename your processed files after each run.   Archiving of the file is typically done on the site where Expenses is pulling the file from and not in your cloud environment.  There is no process on the Oracle side that will move a file on a 3rd party HTTPS/SFTP server.  You will need a mechanism to move the file to another folder automatically after the file is processed so a new file with the static name can be picked up in the next run.  This is specific to Diners, MasterCard and Visa.

Oracle Fusion Cloud ERP Expenses uses SFTP based connections to download data from American Express servers.  HTTPS is no longer supported with American Express.  American Express places their files in a folder called ‘outbox’.  There is often more than one transaction file in a day, but they do not use a static filename.  Every file has the date/timestamp included in the name.  Additionally, when Expenses pulls the file from American Express, the file is automatically moved to the ‘sent’ folder.

Credit card transaction files cannot be loaded into Oracle using a REST API, manually or via a spreadsheet.  Credit card transaction files can only be uploaded to Oracle Expenses using the Upload and Validate Corporate Cards program.

For additional details on setting up an HTTPS or SFTP connection, see the Credit Card Data (Chapter 2) of the Implementing Expenses document located here: https://docs.oracle.com/en/cloud/saas/financials/25b/faiex/index.html

Conclusion

The benefits of credit card integration far outweigh manual processing.  You will reduce human error, increase payment data security, streamline operations, and save time.


For more details on configuring corporate credit card integration, see Using Expenses documentation.