Set the default IP1 environment for credit card payment processing for Braintree, SecurePay, DataCash and CyberSource payment gateways. Other gateways use the default environment set in the transaction ID.

System defined control file – holds encryption algorithms used by the different payment gateways. This control file is no longer applicable; it was used by Payment Manager in earlier versions of IP1.

Setup the Service Providers for credit card processing and the IP1 plug-in programs that apply to the respective service provider.

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:

• AVS – verifies the address of the credit card holder (Address Verification Service); must be = 1 if AVS & CVV verification is required by the payment gateway. 
• BTAVSS – this is for Braintree address verification for street. Allows you to blacklist certain response codes from Braintree. You can enter up to 6 response codes joined by OR condition (no separator, just a string of up to 6 single digit codes). Refer to SOP Braintree Payment Gateway for the possible list of response codes from Braintree.
• BYAVSZ – this is for Braintree address verification for postcode. Allows you to blacklist certain response codes from Braintree. You can enter up to 6 response codes joined by OR condition (no separator, just a string of up to 6 single digit codes). Refer to SOP Braintree Payment Gateway for the possible list of response codes from Braintree. 
• BTCVV – this is for Braintree fraud management for Card Verification Value (CVV). Allows you to blacklist certain response codes from Braintree. You can enter up to 6 response codes joined by OR condition (no separator, just a string of up to 6 single digit codes). Refer to SOP Braintree Payment Gateway for the possible list of response codes from Braintree. 
• 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. 
• EMAIL – default email for the merchant; this is used by CyberSource only.
• INFO – this field is no longer applicable. It was used for masking the credit card number; probably in the earlier versions of IP1. Now the Payment manager program masks the first 12 digits of the credit card number. WEB and EDI orders are accepted as masked into IP1, i.e. IP1 does not mask it any further.
• LIVE – this was specific to South  Africa in earlier version of Payment Manager; not used anymore.
• LOGIN – This field is only used by DataCash. Its the customers merchant account ID for DataCash. DataCash uses this field for merchant ID instead of MERCHANT field..
• MERCACNT – merchant account (as setup with the payment gateway). Used by Braintree only; within the merchant account there can be multiple merchant account IDs (MERCHANT) for different countries, currencies etc.
• MERCHANT – merchant account ID (as setup with the payment gateway). 
• PAD0 = Address1
• PAD1 = Address 2 
• PAD2 = Address3
• PAD3= City
• PAD4 = State
• PAD5 = Postcode
• PAD6 = Country
• PN– sets what goes to Payment Gateway as IP1 primary reference “consumer_id”. If PN=1, then it is process number, otherwise customer number.
• PASSWORD – password for merchant account ID to access the service providers gateway. This is used by DataCash and SecurePay only. 
• PXPRT – proxy port – provided by the customer if applicable. 
• PXURL – URL for the proxy server – provided by the customer if applicable. 
• PXUSR – proxy user for the proxy server – provided by the customer if applicable. 
• PN – sets what goes to Payment Gateway as IP1 primary reference “consumer_id”. If PN=1, then it is process number, otherwise customer number. 
• REFTYPE – Defines the label on the hosted pages (landing page) for the Primary Reference field ‘PN’ (See PN above). For example if PN = 1 (process number) then REFTYPE = ‘Transaction ID’. Used by SecurePay only.
• URLL – URL for the Payment handlers landing page for initial card capture . 
• URL – the URL used for secondary transaction remote calls to the payment handler service. 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 handlers landing page for initial card capture . 
• URLT – URL for any triggered (subsequent) transactions – used by SecurePay only. 
• VLDAMT – amount to be used for the dummy transaction for credit card validation. Some countries and payment gateways allow $0 validation. 
• 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 response. 
• WRNCDE – list of warning codes to ignore (3 digit error responses); no separator, just a string of 3 digit codes e.g. “BT TEST WRNCDE 200201230520”. Used by CyberSource and Braintree. 

Note: Please refer to the SOP for the service provider to see which of the above fields are to be setup for each of the service providers. 

Set  INFPGM to the payment manager program that retrieves the billing/email addresses, for the payment gateway.

Example

for Braintree = XAO644PN

for DataCash = XAO638PN

for CyberSource = XAO641PN

Define all the credit card payment types and the following flags for each  credit card payment type:

• A/C val – this is now obsolete – no longer used. It used to 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, set it to G = Payment
• Auto payment – Yes/No flag indicates if the payment type is for eligible for auto credit card processing or manual. If manual then the Payment manager programs are not activated and the credit card verification is done manually.
• 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.

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.

Setup any user access authorisation for any of the payment or journal types. This is optional; blank entry in this control file will disable security checking.

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. For credit card number field (CCN) the system enforces it to output only, regardless of the setting here.

• ‘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. If the Payment gateway requires validation amount then the amount specified on ********/PM-FLD field VLDAMT will be used.
• 4 = validate the credit card details without CC Manager i.e. offline without interfacing to the payment gateway. This will check on the length of the credit card number, date etc.
• ‘5’ = pre-authorise (approximate). The credit card would be pre-authorised on order entry. 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.

This control file determines when and if credit card pre-authorisation is to be carried out at pending or release to pick:

• 0=pre-authorisation to occur when the order is checked for pending
• 1=pre-authorisation to occur when the order is released for picking.

Note: If set to pre-authorise either at pending or release to pick; this system will only pre-authorise if the amount has increased or any existing pre-authorisation has expired. Pre-authorisation at pending or pick release will not occur if it is not flagged in this control file, i.e. if blank.

TMDSDS/POS-CASH POS entry: Cash entry policy by shop

POS can also be set to pre-authorise or charge at shop level.

TMSAR/BK-CCSUR Credit Card Surcharge 

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

TMSAR/BK-CPAYT Credit card must balance

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.

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