Credit Card Interface overview

Processing technology

The Distribution SX.e Credit Card Interface uses a direct connection to CenPOS' secure web browser using the URL settings you specify in SA Credit Card Processor Setup. The information in the URL settings is used by the interface to identify where the web object resides and what pages to call for each process.

The Credit Card Interface directly invokes the CenPOS web object from the HTML5 user interface inside an inline frame (iframe). This connection directly loads the appropriate credit card form in the CenPOS window, such as Create Token, Modify, and One Time Auth; these forms are displayed during tendering in Sales Order Entry.

The CenPOS context application is automatically added during implementation Distribution SX.e and is not accessible from Infor Ming.le™, as are other context applications.

Distribution SX.e uses service interface calls to update the credit card transaction table (which updates the Distribution SX.edatabase) when a transaction is completed in Sales Order Entry. Distribution SX.e uses service interface calls to close the CenPOS window when a transaction is completed.

Credit card security

PCI standards require that you protect credit card information in multiple ways. You must protect data during storage and transmission. With a hosted payment solution, such as CenPOS, your credit card processor stores and protects your customer cardholder data (CHD) in their servers, so you no longer need to store or managed CHD locally in your systems.

In addition, because the CHD is input directly into CenPOS’ system and not into Distribution SX.e, other users do not have access to the data.

You can still limit operator access to credit card-related modules using SA Operator Setup-Function Security . For example, you may want to limit operator access to Customer Credit Card Setup.

Keep in mind that, because your operators are handling cardholder data (CHD), you must still meet other PCI requirements pertaining to data access. For more information on PCI compliance, including data access requirements, visit the Official PCI Security Standards Council Site (https://www.pcisecuritystandards.org/).

You can enable your operators to modify token information in sales order entry. Typically, system administrator-level operators can modify token information in Customer Credit Card Setup.

See Modifying credit card token information.

However, if you want to grant customer service representative (CSR)-level operators the ability to modify a limited amount of token information from within Sales Order Entry, you can grant them access from SA Operator Setup.

This access is beneficial if, for example, a CSR is entering an order and the card is denied because the expiration date is not current. The CSR can click Modify Tokenized Card during order entry and update that customer's card expiration date through the CenPOS form. We recommend training CSRs to limit changes to only the expiration date. The Modify Tokenized Card button is unavailable in Sales Order Entry if the operator is not granted access.

See Setting up credit card security.

If you block credit card creation in SA Administrator Options, the Modify Tokenized Card setting in SA Operator Setup,-Entry Options-OE Entry Options is ignored.

Processing methods

The Distribution SX.e Credit Card Interface uses two methods for credit card processing.

The first method is a two-step authorization/settlement process, using the AUTH/FSAL transaction types, that is typical of the Mail Order/Telephone Order (MOTO) industry.

• Step 1 is authorization, which reduces the cardholder’s available credit amount until the order is shipped and invoiced. An authorization against a credit card is typically good for 6 or 7 days, depending upon the bank. This process guarantees the merchant that the funds will be available when the goods are shipped and invoiced.
• Step 2 is settlement, which occurs after the order is invoiced. The authorized transaction becomes inactive and a new transaction is created for settlement. During settlement, funds are transferred from the cardholder’s bank to the merchant bank.

The second method is a One Time Sale process where the tendered amount is authorized and immediately settled at the time of purchase. This process is also known as instant payment. This process is typically used in the retail industry in a counter environment. Or, you may also use the one-time process if you want to take a down-payment on a large order or a non-refundable down payment on a high dollar non-stock order. With the CenPOS integration, this transaction method is considered tokenless, because the transaction is authorized and settled immediately, and the token is not stored.

Basic workflow

This is a basic workflow for processing a credit card transaction:

1. The operator enters a sales order in Sales Order Entry and tenders the credit card payment using the Collect Payment view. The operator selects the predefined credit card token, or specifies one during the order entry. The system sets the credit card history transaction code to AUTH.
2. The Distribution SX.e system sends a request for credit card authorization to the credit card processor. Authorization requests can be sent either during Sales Order Entry, at the time of order processing, or from batch approval in Customer Credit Card Manager Report, which you can schedule to run periodically through the day.
3. The credit card processor processes the transaction authorization request and submits the transaction request to the bank that issued the credit card.
4. The bank checks the cardholder’s funds, approves the transaction request, and sends transaction approval to the credit card processor. The bank holds the authorized funds in reserve until either the transaction is settled or the authorization expires.
5. The credit card processor sends an approval message and authorization code to Sales Order Entry-Collect Payment-Process Payment.
6. The operator finishes the sales order.
7. When invoice processing runs, it begins with validation to check whether orders can be invoiced.
8. The AUTH transaction is deactivated and a new entry with a transaction code of FSAL is created.
9. The FSAL transaction is sent to the credit card processor for settlement.
   • If the FSAL fails, invoice processing does not update or invoice the order. An exception is created.
   • If the FSAL succeeds, the credit card processor notifies the bank. Funds are charged to the cardholder’s account and transferred to your bank.
10. As the Sales Entry Processing Invoice Processing Report runs, the invoice is moved to Paid stage. The General Ledger is updated.
11. To view any orders with credit card issues that must be resolved, use the Sales Invoicing Exception Inquiry, or the Sales Entry Processing Invoice Processing Report exception report. These reports also include non-credit card issues.
12. You can run Customer Credit Card Manager Report in Invoicing Mode for the next day to report on FSAL/SALE/RETN transactions run by Sales Entry Processing Invoice Processing Report.