1. Home
  2. /
  3. V12 Documentation
  4. /
  5. Standard Operating Procedures
  6. /
  7. Payment Manager
  8. /
  9. CC Payment Process

CC Payment Process

The process to handle and validate the credit card data via an external payment gateway is:

iSeries will execute the call to the web portal, passing the relevant URL with the parameters required to access the payment gateway to process credit card payment. This would include the process number of the transaction, payment amount, merchant ID and details of the order. It would also include the flag that determines if the payment is to be deducted or authorised with a return of a token.

The web portal will then transfer controls to payment gateway where the user can enter the credit card details, expiry date and the CCV number. The entered details are then verified and pre- authorised or charged. On pre-authorisation a token would be issued. The payment results including the token if issued would then be passed to the web portal which will in turn link to the program in the iSeries that would receive the confirmation and deal accordingly with a negative or positive response.

In IP1 there is fundamentally three ways to charge Credit Card payment depending on the type of order or type of payment process:

  1. Charge at order entry
  2. Pre-authorise credit card
    1. on pending check or
    2. release to pick and settle at invoice
  3. Validate credit card on order entry and charge at invoice

POS (Point of sales) orders are normally configured (in TMSDS/POS-CASH) to do 1 or 2.

Normal Orders via sales order entry (DSE005) can be configured to do either of above (in TMSDS/OM-PAYTL)

Web orders are hard coded to do 2.

Credit card payment via cash entry (ARE005) will charge on entry.

When validating credit cards, system uses the validation amount as setup in control file ********/PM-FLD. When charging or pre-authorising credit card, system uses full invoice/order value.

The system can be configured to pre-authorise credit card on pending check (for backorders) or prior to picking orders (TMSDS/OM-PAUTH). If flagged to pre-authorise on order release for picking and the pre-authorisation fails, then the order will not be released to pick and will be transferred to the sub-order category defined in TMSDS/OM-PAUTH so that users can review all failed orders under the sub-order category.

Configuration setup

Control files

View Control files setup

Business rules for Payment Manager must be setup with support from Iptor consultants.

It is critical to understand the setting of control files and how it works. Control files must be setup correctly for the system to operate as intended. Any changes to the control files setup should be addressed cautiously and in consultation with Iptor IP1 consultants.

The following business rules has to be setup/maintained to handle credit card payment processing. This document does not cover customised setup tasks of specific companies. The purpose of this document is to assist Iptor consultants, setup appropriate business rules at a customer site for the specified process.

Note:  Deviations from this setup should be covered by setup tasks written by individual companies.

Control file  Setup
********/PM-SYS Payment manager processing systems Setup the Service Providers for credit card processing and the plug-in programs that apply to the respective providers.
********/PM-FLD Payment manager static fields 

Use the configuration information gathered from the service provider to set up the various required fields for the respective service provider in this control file. Available fields are:

  • DEBUG – can have the value of 1 or 2 only, even though there is no validation on it. The transaction will process for both values but option 1 gives additional technical data on the transaction being processed, for investigational purposes. 
  • MERCHANT – merchant id for the service provider
  • PASSWORD – password to access the service providers gateway
  • PXPRT – proxy port – provided by the customer
  • PXURL – URL for the proxy user – provided by the customer
  • REFTYPE – SecurePay landing page reference
  • URL – service providers URL. If the URL address is too long, split it between the two fields URL01 and URL02, otherwise use field URL. 
  • URLL – URL for the Payment handler landing page
  • URLT – URL for any triggered (subsequent) transactions – used by SecurePay.
  • VLDAMT – amount to be used for the dummy transaction for credit card validation. It is mandatory and must be entered for all service providers.
  • VLDAUTH – has the number of days/hours to hold the pre-authorisation. Format is 1DDHH, where ‘1’ = yes, ‘DD’= days and ‘HH’=hours. On backorder release when the order goes through pending check it can re-authorise (based on TMSDS/OM-PAUTH) if the number of days/hours has passed since initial authorisation. If authorisation days is not defined for the service provider then the system will default to 10 days. 
  • WAIT – time in seconds for iSeries to wait for landing page.
  • WRNCDE – list of warning codes (3 chars) to ignore.

Please refer to the SOP for the service provider to see the values required for each of the service providers. 
********/PM-OPT Payment manager configuration This control file is only used for SecurePay test environment.
********/PM-CRD Card types  Define all the valid credit cards that can be used for card payments – system defined.
TMSAR/BK-PAYT Payment/journal types

Define all the credit card payment types and the following flags.

  • A/C val – the program entered here validates and formats the bank account to suit most Australian banks like Westpac, National etc.
  • Curr – the payment type can be restricted to receive payments only in the currency listed here. If no currency is entered, the restriction does not apply.
  • Tax – set this flag if tax is to be calculated on certain payments/journals e.g. bad debt for GST recovery. 
  • Dep.prt – this flag determines whether or not the transactions with a particular payment type should print on a deposit slip. Regardless of this flag setting, the transaction will always print on the working version for ease of balancing.  It is only the final version that will print/not print the transaction based on this flag.
  • TR DT – AR transaction document type
  • Auto payment – Yes/No flag indicates if the payment type is for eligible for auto credit card processing or not.
  • DT – Document Type, either as a payment, journal, discount or on account.  Document type ‘0’ = On Account is used for Web based payments.
  • DST – Document Sub-type, either as 1=cash, 2=cheque, 3=credit card, 4=internal voucher, 5=internal voucher transfer, 6=external voucher, 7=external voucher transfer.  
  • Draft – whether or not the payment type is a draft or not.
TMSAR/BK-PAYTD Default payment/journal types for debtors entry

This control file defines payment/journal types that are used as default type for system generated A/R transactions. All payment/journal types defined here should exist in TMSAR/BK-PAYT.
TMSAR/BK-SEC Banking payment/journal types security by user

Setup user access authorisation for any of the payment or journal types.
TMSAR/PM-PTFV1 Valid date range by payment type/field 

Setup valid date range for all fields that are flagged with field type = ‘X’ (credit card start/expiry date) in control file TMSAR/PM-PTFLD.
TMSAR/PM-PTFLD Required fields for payment type

For each payment type define the reference fields and the order in which it will appear on the Bank Reference Entry panel (ARE210).

  • Payment type – payment type as defined in TMSAR/BK-PAYT
  • Seq – this is the sequence in which it will appear on the Bank Reference Entry panel (ARE210)
  • Field – the reference field for data entry
  • Description – reference field description
  • Type – data type (A – string, N – numeric, D – date, T – time, X – MMYY)
  • Length – length of the reference field data
  • Opt – option to have the field as 1 = Optional, 2=Mandatory, 3=Output only
TMSAR/PM-PTOPT Valid options by payment type/field Define the valid values for each of the Payment type fields as defined in TMSAR/PM-PTFLD
TMSDS/OM-PAUTH Pre-Authorization Credit Card payment This control file determines when a credit card pre-authorisation is to be carried out:

  • 0=when the order is checked for pending
  • 1=when the order is released to pick.

When it is flagged to pre-authorise at pending & the pre-authorisation fails, the order can pend for pending code ‘AH’ (if pending rule is defined for pending code ‘AH’). On backorder release when the order goes through pending check it can re-authorise if the number of days/hours to hold pre-authorisation has passed. This is held under field VLDAUTH in control file ********/PM-FLD.
When it is flagged to pre-authorise at release to pick and pre-authorisation fails, the order will not be released to pick and will be transferred to the sub-order category defined in this control file so that user can review all failed orders under the sub-order category.
Pre-authorisation at pending or pick release will not occur if the flag is blank.
 TMSAR/BK-CRDC Credit Card Control This control file defines the control rules for the credit card payment types. The payment type must initially be defined in TMSAR/BK-PAYT.
Charge ONCE only is used where a credit card is pre-authorised externally and should be settled ONCE only using the externally generated token. 
TMSDS/OM-PAYT3 Payment types allowed for payment type list  Setup all the valid payment types for each of the payment type lists.
TMSDS/OM-PAYTL Payment type list for program  This control file determines which payment list (list of payment types as defined above in TMSDS/OM-PAYT3) is to be used by specific programs and which of the following credit card processes the program should do:

  • ‘1’ = charge, the credit card payment would be charged immediately at order entry. The amount charged will include any backorder deposit as defined in TMSDS/CM-PAYT.
  • ‘3’ = validate credit card details via CC Manager
  • ‘5’ = pre-authorise (approximate). The credit card would be pre-authorised on order entry and the authorised amount will depend on backorder deposit % defined in TMSDS/CM-PAYT.

If set with option ‘5’ to pre-authorise and the payment terms (TMSDS/CM-PAYT) is specified 100% deposit for backorder, then Bookmaster will pre-authorise for full order amount including backorder amount at the order entry and settle with full order amount at the invoice time.
If set with option ‘5’ to pre-authorise and the payment terms specified 0% deposit for backorder, then Bookmaster will pre-authorise for full invoice (delivered) amount excluding backorder amount at the order entry and settle with full invoice amount at the invoice time.

TMSAR/BK-CCSUR Credit Card Surcharge 

Setup the credit card surcharge percentage to be charged by company/payment type/credit card type if applicable.

Merchant details

The default credit card provider for the system is maintained in Merchant Details Maintenance in the Cross Application Support module.  Payment Manager program(XAO630) will determine the service provider and the merchant ID based on this setup (Payment manager file – XAPMA00P).

Credit Merchant Detail Maintenance

To setup or maintain merchant details

  1. Expand menu Other Options > Cross Application Support > Payment Manager > and double- click n Credit Merchant Detail Maintenance (XAW630). The existing service providers already in the system is listed.

  1. Select the service provider and click option Change to maintain the selection fields that are applicable to the service provider or
  2. Click Add to add the selection details for a new service provider. The service providers must be setup in control file ********/PM-FLD first. In credit card payment processing the default service provider will be selected based on the sequence number and the selection values entered here.

Credit card transaction ID

XA-TRNID control number

For credit card transaction ID, setup control number key XA-TRNID with a high limit. This transaction ID will be allocated to each credit card transaction processed in IP1.

Payment processing

Payment/charge at Order entry

 Task Instructions

Enter your order via DSE005 or DSE095
  1. Ensure the Payment type list for the order entry program DSE005A is set to 1 = Charge on control file TMSDS/OM-PAYTL. 
  2. Enter your order via DSE005 or DSE095.
  3. Flag Payment terms to prompt payment on the order if via DSE005.
  4. Enter the order details and confirm the order to display Payment entry panel (DSE131):

  1. Enter the amount to pay and the credit card Payment type in the Amt tendered and Mth fields.

  1. Click confirm.  Service provider (SecurePay in this example) will display their payment entry panel to enter the credit card details to validate the credit card.

  1. Enter the credit card details and click Continue.

  1. If the credit card details displayed are correct then click Make Pre-authorisation. The Service provider will validate the credit card using the validation amount as set in the control file ********/PM-FLD for the service provider. After successful validation, the receipt of the validation is displayed.

  1. Close the receipt page. You will then be directed back to the IP1 payment entry panel with the message ‘Approved’ in the Message column and the Banking reference updated.

  1. Click F10=confirm. The payment amount will now be processed/charged.

View the payment transaction
  1. To view the payment,  expand menu Other Options > General Inquires > Customer Inquires > and double- click Transactions by Customer inquiry, enter the customer number and click OK.  All the transactions for the selected customer is listed.
  2. Select the order that was entered above and right click Orig document. The selected order is displayed.
  3. Click function F13=Payment to view the payment transaction for the order. The credit card amount charged is reflected in the payment transaction. 

Validate credit card on order entry time and charge at invoice time

Task Instructions
Validate CC on order entry
  1. Ensure the Payment type list for the order entry program (DSE005A) is set to 3 = Validate via CC manager on control file TMSDS/OM-PAYTL. 
  2. Enter the order (via DSE005A); ensure the Payment terms on the order is prompt.
  3. Enter the order details and confirm order. Payment entry panel (DSE131) appears.

 

  1. Enter the amount to pay and the credit card Payment type in the Amt tendered and Mth fields and click confirm. Service provider (SecurePay in this example) will display their payment entry panel to enter the credit card details to validate the credit card.

  1. Enter the credit card details and click Continue.

  1. If the credit card details displayed are correct then click Pre-authorisation. The Service provider will validate the credit card using the validation amount as set in the control file ********/PM-FLD for the service provider. After successful validation, the receipt of the validation is displayed.

  1. Close the receipt page. You will then be directed back to the IP1 payment entry panel with the message ‘Approved’ in the Message column and the Banking reference updated.

  1. Click F10 to confirm.
View Payment inquiry
  1. To view payment transaction expand menu Other Options > General Inquires > Customer Inquires > and double- click Transactions by Customer inquiry, enter the customer number and click OK.  All the transactions for the selected customer is listed.
  2. Select the order that was entered above and right click Orig document. The selected order is displayed.
  3. Click function F13=Payment to view the payment for the order.

Note: Auth code = 2 means the order has been not been pre-authorised. The credit card is only validated i.e. not charged, therefore the payment amount is not reflected in the transaction.
Charge CC at invoicing On invoicing the payment amount will be processed/charged with the validated credit card details.

Pre-authorise credit card

Orders can be configured to pre-authorise when the order is checked for pending (DSO040) or released to pick (WHM070); depending on the setup in TMSDS/OM-PAUTH. The order amount can be pre-authorised but the amount charged at dispatch will be the actual invoice amount, even if the invoice amount is different to the pre-authorised amount.

Web Orders are hard coded to pre-authorise on order entry and settle at invoice time.

Task Instructions
Pre-authorise on pending check
  1. Ensure the Payment type list for the order entry program DSE005A is set to 5 = Pre-authorise(approximate) on control file TMSDS/OM-PAYTL. 
  2. Ensure the control file TMSDS/OM-PAUTH is set to pre-authorise credit card on Pending. 
  3. Enter your order via DSE005.
  4. Flag Payment terms to prompt payment on the order if via DSE005.
  5. Enter the order details and confirm order display Payment entry panel (DSE131).

  6. Enter the amount to pay and the credit card Payment type in the Amt tendered and Mth fields and click confirm. Service provider (SecurePay in this example) will display their payment entry panel to enter the credit card details to pre-authorise the order amount.

  7. Enter the credit card details as in the above example and confirm the transaction.

  8. To view the pre-authorisation, go to DSI120 Transaction Inquiry and click function F13=Payment.

Note 1: Auth code = 3 means the order has been pre-authorised for the approximate amount as displayed and the actual amount charged at invoicing may vary.

Note 2: If the order 

If pre-authorisation fails at pending check, the order will pend with pending code ‘AH’= ALLOCATED CASH VIA CREDIT CARD. You can review the pended orders through Pending Review (DSE025).
Pre-authorise on release to pick
  1. Ensure the Payment type list for the order entry program (DSE005A) is set to 5 = Pre-authorise(approximate) on control file TMSDS/OM-PAYTL. 
  2. Ensure the control file TMSDS/OM-PAUTH is set to pre-authorise credit card on Release to Pick. 

If pre-authorisation fails the order will not be released to pick and will be transferred to the sub-order category defined in control file TMSDS/OM-PAUTH so that user can review all failed orders under the sub-order category.

Credit card surcharge

If a credit card charges a surcharge then the system can add the surcharge amount onto the payment amount when settling the payment amount. TMSAR/BK-CCSUR must be setup for the company, payment type, credit card type and debtor class with the surcharge percentage that has to be charged. The surcharge will be incurred if the payment amount is under a minimum amount. 

If a credit card surcharge is charged then the system will generate a journal for the surcharge amount if the journal type is specified in TMSAR/BK-CCSUR. If a surcharge item is defined instead on TMSAR/BK-CCSUR, then the system will generate a surcharge invoice (DSTR*) instead of a surcharge journal (ARTR*) so that it can print a surcharge invoice.

Work with failed credit card

Credit card transactions that have failed due to incorrect credit card details can be amended and re-processed with this program. Refer to Work with failed credit card for information on this process.

Print Friendly, PDF & Email