ipay business logic guide - planet · ipay business logic guide. gateway specification. version...

iPAY Business Logic GuideGateway Specification

Version 4.2.1 | Update 1/16/19

Notice: This document contains confidential, trade secret information, which is proprietary to Planet

Payment, Inc., and its subsidiaries (collectively Planet Payment®) and is provided solely for recipient’s

use in connection with recipient’s participation in one of Planet Payment’s Processing Programs. Planet

Payment reserves the right to make changes to specifications at any time and without notice. The

information furnished by Planet Payment in this publication is believed to be accurate and reliable as of

the date of its release; however, no responsibility is assumed by Planet Payment for its use, nor for

infringements of patents or other rights of third parties resulting from its use, nor for the violation,

misinterpretation, or misapplication of any laws, or any regulation of any credit card association

including Visa, Inc., or MasterCard, Inc. No general license is granted under any patents, copyrights or

other intellectual property rights owned by Planet Payment and the recipient is only granted an end user

license to use this information for the purposes of participating in one of Planet Payment’s Processing

Programs, pursuant to an agreement with Planet Payment or one of its authorized Program partners. All

modifications or improvements to any of the information and specifications in this document shall

belong exclusively to Planet Payment, Inc. No unauthorized copying, disclosure or use of this document

is permitted without the express written consent of Planet Payment, Inc. Planet Payment®, Pay in Your

Currency®, BuyVoice®, iPAY® and the globe-and-ring logo are trademarks and/or registered

trademarks of Planet Payment, Inc.© 2018 Planet Payment, Inc. All Rights Reserved

Business Logic Guide

Contents

1. Introduction ....................................................................................................................... 11.1 Scope ......................................................................................................................................... 2 1.2 Multi-Currency Pricing (MCP) ..................................................................................................... 2 1.3 Data Retention Policy ................................................................................................................. 4 1.4 System Maintenance .................................................................................................................. 4 1.5 Annual Code Freeze ................................................................................................................... 4 1.6 Supported Payment Methods ..................................................................................................... 5

2. Association Certification and Compliance ..................................................................... 63. Transaction Definitions .................................................................................................... 7

3.1 Transaction Responses and Data Security ................................................................................ 7 3.2 Credit Card ................................................................................................................................. 7 3.3 ACH ............................................................................................................................................ 8 3.4 Recurring Transactions .............................................................................................................. 9

3.4.1 Recurring Transaction Features ...................................................................................................... 11

3.4.2 Recurring Billing Scenarios .............................................................................................................. 14

3.5 Repository Transactions ........................................................................................................... 16 3.6 Template Transactions ............................................................................................................. 16

4. Credit Card Transactions ............................................................................................... 174.1 Transaction Request Process—iPay Gateway System ............................................................ 17 4.2 Transaction Requirements—iPay Gateway System ................................................................. 17 4.3 Transaction Overviews ............................................................................................................. 20 4.4 Merchant Responsibilities for CC Transactions ........................................................................ 23

4.4.1 Basic Transaction Requirements ..................................................................................................... 23

4.4.2 Merchant Responsibilities for Sales Transactions ........................................................................... 23

4.4.3 Credit Card Sales Receipt Data Requirements ............................................................................... 23

4.5 Card Security Validation Procedures (Card Present) ............................................................... 24 4.6 Cardholder Verification Procedures (card not present) ............................................................ 25

4.6.1 CVV .................................................................................................................................................. 25

4.6.2 Enrolling in CID ................................................................................................................................ 27

4.6.3 AVS .................................................................................................................................................. 28

4.6.4 Verified by Visa and MasterCard SecureCode ................................................................................ 30

4.7 Merchant Responsibilities for Credit Card Refund Transactions .............................................. 31 4.7.1 Sales Receipt Data Requirements for Credit Card Refunds ........................................................... 31

4.8 Other Functionality Highlights ................................................................................................... 31 4.8.1 The iPay Gateway TRANSACTION_ID ........................................................................................... 31

4.8.2 Merchant Descriptor ........................................................................................................................ 32

4.8.3 Bill Payment Indicator ...................................................................................................................... 32

4.8.4 Transaction History .......................................................................................................................... 33

4.8.5 Invalid Data Scrubbing ..................................................................................................................... 33

DEV_ Specification 2014iPAY Buisness Logic - 2019

Copyright © 2014-2019 Planet Payment Inc. All Rights ReservedConfidential and Proprietary Information

i


4.9 Currency Conversion ................................................................................................................ 36 5. Credit Card Disputes ...................................................................................................... 37

5.1 Retrieval Request/Request for Copy ........................................................................................ 37 5.2 Chargebacks ............................................................................................................................ 37

5.2.1 Visa Request for Copy Reason Codes ............................................................................................ 49

5.2.2 MasterCard retrieval request reason codes .................................................................................... 49

5.2.3 Visa Chargeback Reason Codes and Actions ................................................................................. 50

5.2.4 MasterCard Chargeback Reason Codes and Actions ..................................................................... 53

5.3 Reducing Your Chargeback Ratio ............................................................................................ 57 5.3.1 Special Notes for Recurring Transactions ....................................................................................... 58

6. ACH Processing .............................................................................................................. 596.1 ACH Payment Types ................................................................................................................ 59

6.1.1 Pre-arranged Payment and Deposit (PPD) ..................................................................................... 59

6.1.2 Cash Concentration and Disbursement (CCD) ............................................................................... 61

6.1.3 Re-presented Check Entries (RCK) ................................................................................................ 62

6.1.4 Point-of-Purchase Entries (POP) ..................................................................................................... 64

6.1.5 Internet-Initiated Entries (WEB) ....................................................................................................... 66

6.1.6 Telephone-Initiated Entries (TEL) .................................................................................................... 67

6.2 ACH Transaction Overviews .................................................................................................... 71 6.3 Merchant Responsibilities for Sales Transactions .................................................................... 74 6.4 Basic Transaction Requirements for ACH Transactions .......................................................... 74

6.4.1 Account Holder Authorization .......................................................................................................... 74

6.4.2 ACH Sales Receipt Data Requirements .......................................................................................... 75

6.5 Merchant Responsibilities for ACH Refund Transactions ......................................................... 76 6.5.1 Sales Receipt Data Requirements for ACH Return ......................................................................... 76

6.6 Other Functionality Highlights ................................................................................................... 76 6.6.1 Transaction History .......................................................................................................................... 76

6.6.2 Invalid Data Scrubbing ..................................................................................................................... 76

6.6.3 ACH Settlement ............................................................................................................................... 76

6.7 ACH Disputes ........................................................................................................................... 77 6.7.1 Returns ............................................................................................................................................ 77

6.7.2 Instant Returns ................................................................................................................................ 77

6.7.3 Monitoring of TEL transactions ........................................................................................................ 77

6.7.4 Fines ................................................................................................................................................ 78

6.7.5 Planet Payment Monitoring .............................................................................................................. 78

6.7.6 ACH Return Reason Codes ............................................................................................................. 79

6.8 ACH Correction ........................................................................................................................ 89 6.9 Sample ACH Authorization Forms ............................................................................................ 95

6.9.1 Sample Credit Authorization to Single Account ............................................................................... 95



ii


6.9.2 Sample Credit Authorization to Multiple Accounts .......................................................................... 96

6.9.3 Sample Debit Authorization ............................................................................................................. 97

6.9.4 Sample Automatic Payment Authorization Form ............................................................................. 98

6.9.5 Sample ACH Return Dispute Form ................................................................................................. 99

7. Web Site Requirements ................................................................................................ 1007.1 Web Site Information .............................................................................................................. 100

7.1.1 Refund Policy Disclosure—Electronic Commerce Merchant ........................................................ 100

7.1.2 Special Circumstances .................................................................................................................. 100

7.1.3 Transaction Receipt Data Requirements ....................................................................................... 101

7.2 Additional Requirements for IPSP merchants ........................................................................ 101 7.2.1 High-Risk Internet Payment Service Provider ............................................................................... 102

7.3 Delivery to Cardholder ............................................................................................................ 102 7.4 Sample Cardholder Information Page .................................................................................... 103 7.5 Sample Web Site Billing Page ................................................................................................ 104

8. Frequently Asked Questions ....................................................................................... 1059. Glossary ......................................................................................................................... 10610. List of Tables ................................................................................................................. 10911. List of Figures ............................................................................................................... 11012. Revision History ............................................................................................................ 111



iii


1. IntroductionThis document outlines the business logic for transactions going through Planet Payment’s iPAY Gateway. However, much of the information covered in this guide also applies to merchants using our other interface options because although the front-end applications are different, all transactions pass through our central database and are subject to the rules governing that database. See Figure 1.

Figure 1 - Overview of the iPAY Gateway System

Depending on the Gateway service or product you have purchased, you may also be supplied with additional manuals. Our current manuals include the Portal User Manual, the iPAY Global Payment Gateway Overview, Business Logic Guide, MWEB User Guide, the App Secure Administrator’s Manual, the Report Delivery System (RDS) Application Programming Interface (API) Guide, the iPAY Gateway API Guide, and the Merchant Testing Guide.


Copyright © 2014-2019 Planet Payment Inc. All Rights ReservedConfidential and Proprietary Information1

Page 1 of 111


1.1 Scope This document includes requirements for correct transaction processing. It is the merchant’s responsibility to read this document thoroughly and meet all requirements noted in this guide.

1.2 Multi-Currency Pricing (MCP) Merchants can increase their global sales with our newly enhanced Multi-Currency Pricing gateway. Multi-Currency Pricing (MCP) helps globally focused card-not-present merchants such as e-commerce, mail order and telephone order merchants target new international markets quickly and increase global sales when their international customers view pricing and pay in their home currencies. Multi-Currency Pricing more effectively turns international browsers into customers—those from Japan enjoy the clarity of browsing and paying in Yen, while those from Britain enjoy the certainty of paying in British pounds. Provided through the convenience of a merchant account offering settlement and reporting in the merchant’s domestic currency (e.g. US Dollars for a US-based Merchant, Euro’s for a European-based merchant), Multi-Currency Pricing does not require that the merchant set up any international entities or overseas bank accounts.

Pricing Methodologies Planet Payment does not actually set prices in foreign currencies – you maintain complete discretion in setting the foreign currency pricing. Rather, as part of the MCP service, we supply you with the rate information that you need to determine the appropriate foreign currency price.

You will need to reflect on your foreign pricing strategy. Below are the two basic questions, which you will need to consider as you refine your approach to MCP:

Is it more important to show your foreign customers a constant price, while you receive adifferent US$ settlement amount based upon daily exchange rate fluctuations? OR

Would you prefer receive a constant US Dollar settlement amount for a given item and allowthe foreign price to vary along with the exchange rate?

To summarize, with MCP, you have the option of either fixing foreign price that your customers will pay or fixing the US Dollar settlement amount that you will receive. This flexible approach to price management allows you define the customer experience and the financial aspects of MCP. These options are called Static MCP and Variable MCP. They are set-up options that a merchant can select when determining how to price goods on a website.

DEV_ Specification 2014 iPAY Buisness Logic - 2019

Copyright © 2014-2019 Planet Payment Inc. All Rights Reserved Confidential and Proprietary Information2

Page 2 of 111


The following table illustrates the key points of both:

Static MCP Variable MCP

o You set your prices in a foreigncurrency and the US settlementamount that you receive fluctuateswith the daily exchange rate

o You have the ability to updateprices as needed

o While the settlement amount youreceive daily for a product changes,the price of a product does notchange daily for the shopper

o You update your price on a daily basis toreflect fluctuations in exchange rates

o Prices are updated daily using the iPAYGateway Currency Rate Querytransaction, which lists the currentexchange rates for the day

o The settlement amount received daily fora product remains constant, but the priceof a product changes daily for theshopper

To summarize, you may price your goods or services in the foreign currency by: o Retrieving a rate table from the iPAY Gateway Currency Rate Query transaction on a

daily basis, or on a less than daily basis (e.g. weekly or monthly) o Utilizing rates obtained from another source (e.g. bank, newspaper, internet)o Creating foreign denominated prices based upon market conditions or your physical

store prices

Website Customization As mentioned above, with MCP, prices are posted in foreign currencies and customers can complete the transaction, from selection to final payment, in their own currency. MCP therefore requires an additional level of website modification, which will vary depending upon on the desired customer experience, such as customizing an entire site based on items such as language, or just the display of pricing. To change the pricing display or to create a new display with a new currency(s) will require your website shopping cart or payment page to support multiple currencies. Often this is managed via currency codes. Additionally, you will need to ensure that your web site has been certified to support Planet Payment’s MCP service, to ensure the proper processing of the MCP transactions.

These are some of the creative elements needed to create a website that can accept multiple currencies: 1. Currency display options, include:

a. Separate URLs/Websites for each country/currency supportedb. Displaying of each currency next to the sale item, and automatically choosing a currency

based on IP Address or entered shipping addressc. Drop-downs or Radio buttonsd. Click on a Flag

2. Website design to accommodate cultural nuances specific to each targeted region’scustomers.

3. Website design to accommodate languages spoken specifically by the targeted region’scustomers.

4. Testing and certification of your web site for processing multiple currency transactions(specifications will be supplied by Planet Payment).

5. A shopping cart or Planet Payment’s Pay Page® payment page that has the ability to acceptpayment in multiple currencies.



Page 3 of 111


1.3 Data Retention Policy Planet Payment keeps merchants’ financial and non-financial transactions available to the merchants for 18 consecutive months.

1.4 System Maintenance The Planet Payment Processing Services typically has two maintenance windows every month—one on the first Thursday and one on the third Sunday (these days may change to avoid holiday weekends). These windows run from 3 a.m. to 8 a.m. (EST), and during this time we perform system upgrades, code pushes, hardware maintenance, etc. Each quarter, we publish a bulletin for our customers listing the dates and time of the maintenance windows. We also detail in the quarterly bulletins any programming changes our customers may have to make due to updates in compliance or association regulation requirements. We strive to give its customers a minimum of 90 days’ notice if they are required to make programming changes.

During the maintenance window, the following transactions may fail: Client modify/delete Account modify/delete Schedule modify/delete

When these transactions are attempted during a system outage, merchants will receive a Message Response Code (MRC) of “SU” (system unavailable).

In addition, during database maintenance, data are stored in message queues; therefore, authorizations processed during an outage will not be in any reports until the databases are brought back online and the message queues are processed.

1.5 Annual Code Freeze Planet Payment has an annual code freeze during which time no coding changes are made to our production systems, unless absolutely necessary. This helps to ensure uninterrupted and trouble-free service to our merchants during the busy holiday retail season. The annual code freeze runs from approximately mid-November to mid-January.



Page 4 of 111


1.6 Supported Payment Methods The iPAY Gateway system supports the following major credit cards:

Visa MasterCard American Express

International Diners Club/Carte Blanche Discover JCB

We support credit card processing in the following formats:

Card Not Presento Mail Order/Telephone Order

Transactionso Basic e-commerce Transactionso Visa Telecommunications

Transactionso Recurringo Preferred e-commerce

transactions (Verified by Visa andMasterCard SecureCode)

o Bill payment/utilities

Card Presento Retail Transactionso Retail with Tipo Restaurant Transactionso Bill payment/utilities

Credit card transaction requirements and processing functionality are fully described in Section 4.

Please note that we support Track 1 and Track 2 data for card transaction, but we do not support Track 3 data.

The iPAY Gateway system currently supports the following consumer ACH Payment Applications: Internet (WEB) Initiated Entries Point-of-Purchase (POP) Entries Telephone-Initiated (TEL) Entries Prearranged Payment and Deposit (PPD) Entries

The iPAY Gateway system currently supports the following corporate (business) ACH Payment Applications:

Cash Concentration and Disbursement (CCD)

ACH transaction requirements and processing functionality are fully described in Section 6.



Page 5 of 111


2. Association Certification and CompliancePlanet Payment is committed to maintaining the highest standards of cardholder and account holder data security in the industry. To that end, we have received and continue to maintain SAS 70 Type II and Visa Cardholder Information Security Program (CISP) certification. Our compliance with Association regulations and our adoption of industry best practices helps to safeguard sensitive customer data against intrusion and fraud.

Moving forward, our focus will be on maintaining Payment Card Industry Data Security Standard (PCIDSS) compliance, which has been endorsed and adopted by many payment brands and subsequently become the industry standard developed by Visa and MasterCard. Our goal is to meet and exceed merchant expectations where security is concerned.

Planet Payment also requires our Level 1, 2, and 3 merchants (see table below) and their third-party providers to demonstrate full compliance with PCIDSS.

Merchant Level Description

1

Any merchant—regardless of acceptance channel—processing over 6,000,000 Visa transactions per year. Any merchant that has suffered a hack or an attack that resulted in an account data compromise. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system. Any merchant identified by any other payment card brand as Level 1.

2 Any merchant processing 150,000 to 6,000,000 Visa e-commerce transactions per year.

3 Any merchant processing 20,000 to 150,000 Visa e-commerce transactions per year.

4 Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants processing up to 6,000,000 Visa transactions per year.

Level 4 merchants must also be PCIDSS compliant, but at this time they are not required to certify their compliance with Visa.

Please note that PCIDSS requirements apply to merchants, Acquirers, processors, and payment gateways that store, process, or transmit cardholder data. Additionally, these security requirements apply to all “system components,” (e.g., network components, servers, or application included in, or connected to, the cardholder data environment).

We also strongly recommend that all merchants adopt Visa’s Payment Application Best Practices (PABP). While the PABP are not yet required by Visa, history has shown that Visa often makes these types of recommendations mandatory within a year or two of publication.

Planet Payment reserves the right to terminate any merchant who is not PCIDSS compliant. For more information, including validation procedures and documentation, visit www.visa.com/cisp and go to the Merchants area. The PCIDSS requirements and the PABP are available for download in a pdf format.



Page 6 of 111


3. Transaction DefinitionsAll gateway system transactions are defined in the tables below.

3.1 Transaction Responses and Data SecurityThe iPAY Gateway takes its responsibility to keep customer data secure very seriously. Wemask account numbers to the last four digits in bulk reports. By limiting the number of timesthese data are transmitted, we reduce the amount of exposure. For more information on thesefields, please see the iPAY Gateway API Guide.

3.2 Credit Card Table 1 - Transaction Definitions for Credit Cards

Legacy system

SERVICE SERVICE TYPE SERVICE

SUB TYPE DEFINITION

C6 CC DEBIT AUTH

A CC DEBIT AUTH is used to obtain an authorization code for funds available and check the billing address of the card and the additional card verification values. This is not a captured transaction and will not settle. The authorization code will be valid for a limited time (three to thirty days, depending on the issuing bank) before “expiring” and releasing the funds to a cardholder’s account. In order to be paid for this transaction type, you must submit a CC capture transaction with the TRANSACTION_ID given from the CC AUTH transaction. In a card-not-present environment, CC AUTH transaction is recommended when using the AVS and CVV responses to decide whether you want to proceed with the sale. In addition, address verification is required if the credit card magnetic stripe is not electronically read.

C5 CC DEBIT CAPTURE

A CC DEBIT CAPTURE transaction causes a previously approved CC AUTH transaction or a voice-approved transaction to be turned into a sale. This transaction requires the TRANSACTION_ID given in a CC AUTH or voice-approved APPROVAL_CODE in order to work. The CC capture transaction requires the entry of the original transaction identifier issued by the gateway and the amount to be captured (if an electronic authorization was obtained through the gateway platform). This transaction identification number can only be used once, unless the capture transaction was voided before settlement. To receive the best rate, you must reference the TRANSACTION_ID from the corresponding AUTH record in your capture record. One authorization code must never be used on two or more capture transactions; it can result in a chargeback (one authorization to one capture). The capture transaction will only be matched to the original Auth transaction within 10 days of the authorization. The gateway system will not honor an AUTH transaction after 10 days. The CAPTURE AMOUNT must be equal to or less than the original AUTH transaction with the exception of service format 1021 (see page 34 for a description of service format 1021).

C1 CC DEBIT SALE A CC DEBIT SALE is an AUTH and CAPTURE transaction all in one transaction. Please see the above CC AUTH and CC CAPTURE transactions.

C2 (not

recorded in DB)

CC DEBIT VOID

A CC DEBIT VOID is used to remove a debit or debit capture sale from a batch before the batch is settled/closed. It prevents a cardholder’s account from being charged. This function cannot be performed on a transaction that has already settled/closed. A sale that has been voided will continue to hold funds from the customer’s open-to-buy until the authorization expires. If a sale has not been settled/closed, it is preferable to use a void transaction to remove the sale, rather than using a credit/return transaction. Each void transaction requires the entry of the original transaction identifier issued by the gateway.

C3 CC CREDIT REFUND A CC CREDIT REFUND is the opposite of a sale transaction. When this



Page 7 of 111


Legacy system

SERVICE SERVICE TYPE SERVICE

SUB TYPE DEFINITION

transaction is settled, it will remove funds from the merchant account and transfer them to the customer’s account. It is used to credit a cardholder for returned merchandise after the sale or capture transaction has been settled/closed. The gateway will reject a refund transaction if the referenced DEBIT transaction has not settled. The merchant should void the DEBIT transaction if it has not settled. Each credit transaction requires the entry of the original transaction identifier issued by the gateway and the amount to be refunded. The credit amount must be equal to or less than the original debit transaction. The merchant can only submit multiple credit requests if the sum of the credits is less than or equal to the total of the original DEBIT transaction.

C2 (not

recorded in DB)

CC CREDIT VOID

The CC CREDIT VOID transaction removes a prior credit transaction from an open batch. It can be used to reverse a mistakenly entered credit/return/refund transaction. It prevents a cardholder’s account from being credited. This function cannot be performed on a transaction that has already settled/closed. Each void transaction requires the entry of the original transaction identifier issued by the gateway.

3.3 ACH Table 2 - Transaction Definitions for ACH

Legacy SERVICE SERVICE TYPE SERVICE SUBTYPE DEFINITION

D or S ACH DEBIT SALE

A debit removes funds from the account holder’s bank account and transfers them into the merchant’s bank account. The transfer of funds takes place on the next business day after settlement has occurred. This is known as the effective date. In addition, this is not a wire transfer, nor is an authorization given for the availability of funds.

B or C ACH DEBIT VOID

A debit void cancels the processing of a debit type transaction before it is settled. It prevents an account holder’s account from being charged. This function cannot be performed on a transaction that has already settled/closed. Each void transaction requires the entry of the original transaction identifier issued by the gateway.

A4 (not

recorded in DB)

ACH CREDIT REFUND

A credit removes funds from the merchant’s bank account and transfers them to the customer’s bank account. The transfer of funds takes place on the next business day after settlement has occurred. This is known as the effective date. Each credit transaction requires the entry of the original transaction identifier issued by the gateway and the amount to be refunded. The credit amount must be equal to or less than the original debit transaction. The merchant can only submit multiple credit requests if the sum of the credits is less than or equal to the total of the original DEBIT transaction.

A4 (not

recorded in DB)

ACH CREDIT VOID

A credit void cancels the processing of a credit type transaction before it is settled. It prevents a cardholder’s account from being credited. This function cannot be performed on a transaction that has already settled/closed. Each void transaction requires the entry of the original transaction identifier issued by the gateway.



Page 8 of 111


3.4 Recurring Transactions Recurring transactions can be divided into two types: recurring payment arrangements and installment payment arrangements.

What is a recurring payment arrangement? A recurring payment arrangement results from an agreement between a cardholder/account holder and a merchant where the cardholder/account holder is billed for goods or services within an ongoing service cycle that is known and agreed upon, in advance, by both the merchant and the cardholder.

Example: Consumer subscribes to an online news web site and pays $9.95 per month until the consumer cancels the online service.

What is an installment payment arrangement? An installment payment arrangement results from an agreement between a cardholder/account holder and a merchant where the cardholder/account holder is billed for goods or services within a multiple payment cycle for specified term, usually until payment has been satisfied, that is known and agreed upon, in advance, by both the merchant and the cardholder.

Example: Consumer buys a vacuum from the merchant for $500.00 and agrees to pay “five easy payments” of $100.00 per month for five months until the entire amount of $500.00 is paid.

The iPAY Gateway system supports both these models.

For both of these payment arrangements, the Card Associations require that the initial payment be differentiated from the subsequent recurring payments. At iPAY, we do that through the use of a transaction indicator. This indicator is automatically assigned in our PS Portal interface. Planet Payment customers who program directly through the iPAY Gateway system must ensure that their transactions are correctly identified as initial or recurring.

In addition, the merchant is required to identify how the initial transaction data were obtained from the cardholder/account holder and provide that information in the transaction message to the gateway. Examples:

Merchant and Cardholder/Account holder are Face to Faceo Card or Account Data were Electronically Read or Key Entered

Mail Order Telephone Order Merchant Attended Telephone Order via ARU Secured Internet Transaction – Home PC

o Channel Encryptedo Other Security Features, such as VBV or MCSC



Page 9 of 111


Both credit card and ACH transactions can be set up for recurring payments. For information on how to program recurring transactions, see the iPAY Gateway API Guide. Recurring transactions can also be set up in the Payment Portal. See the PS Portal User Manual. Table 3 - Transaction Definitions for Recur

SERVICE SERVICE TYPE SERVICE SUBTYPE DEFINITION

RECUR CLIENT INSERT

A CLIENT insert is the base transaction for inserting a recurring transaction into the gateway system. This transaction inserts the CLIENT, ACCOUNT, and SCHEDULE records. The CLIENT record must have at the very minimum of one ACCOUNT record related to it at all times.

RECUR CLIENT MODIFY The MODIFY transactions allows the modification of a single or multiple fields to the CLIENT record.

RECUR CLIENT DELETE

This transaction will delete the CLIENT record. Since the CLIENT record is the base of the recurring transaction, all related ACCOUNT and SCHEDULE records would also be removed once the CLIENT is deleted.

RECUR ACCOUNT INSERT

This transaction will insert a new ACCOUNT. SCHEDULE data is also required when inserting a new ACCOUNT. The CLIENT_ID from a previous CLIENT INSERT must also be supplied with this request. The ACCOUNT record must have at the very minimum of one SCHEDULE record related to it at all times.

RECUR ACCOUNT MODIFY The MODIFY transaction allows the modification of a single or multiple fields to the ACCOUNT record.

RECUR ACCOUNT DELETE

This transaction will delete the ACCOUNT record. If the ACCOUNT record is the only ACCOUNT related to a corresponding CLIENT, the transaction will be rejected due to data integrity violations (see CLIENT INSERT). All related SCHEDULE records would also be removed once the ACCOUNT is deleted.

RECUR SCHEDULE INSERT This transaction will insert a new SCHEDULE. The CLIENT_ID from a previous CLIENT INSERT must be supplied as well as the ACCOUNT_ID from a previous ACCOUNT INSERT with this request.

RECUR SCHEDULE MODIFY The MODIFY transactions allows the modification of a single or multiple fields to the SCHEDULE record.

RECUR SCHEDULE DELETE

This transaction will delete the SCHEDULE record. If this SCHEDULE record is the only SCHEDULE related to a corresponding ACCOUNT, the transaction will be rejected due to data integrity violations (see ACCOUNT INSERT).

RECUR SCHEDULE REPLACE This transaction replaces an existing SCHEDULE with a new SCHEDULE. The original SCHEDULE is CANCELLED, and the new SCHEDULE is INSERTED.

Recurring transactions can reference templates, which reduces the number of XML fields that need to be submitted for recurring transactions. See the following sections.



Page 10 of 111


3.4.1 Recurring Transaction Features A number of features are available in recurring transactions. See below.

3.4.1.1 Prepay versus Postpay In the Payment Portal and in the Gateway, recurring transactions must be identified as pre pay or post pay.

Pre Pay means that the customer is charged before consumption of the service for the full amount of the billing cycle (much like paying rent at the beginning of the month for that month).

Post Pay means that the customer is charged after the consumption of the product and is billed for the amount of product or service used for that billing cycle (such as minutes for a cellular phone).

In the pre-pay mode, the customer is charged before the consumption of the service (i.e., the selection of pre pay or post pay has an effect on how residual amounts are handled when a schedule is replaced or canceled. See below).

3.4.1.2 Process Residual This function controls how residual funds for replaced and canceled schedules are handled. The selections for this option are Yes or No and every transaction must have an associated Process Residual designation. The meaning of these options depends on the Pre Pay or Post Pay selection.

Process Residual with Pre Pay scenario Selecting Yes means that a customer will receive a refund for any residual amount remaining for an existing schedule when that schedule is cancelled or replaced. The customer will see a refund on his/her card or bank account statement.

Note: If the customer replaces an existing schedule with a different product (i.e., upgrades or downgrades), he/she will see two transactions on his/her statement—one refund transaction for the residual value of the previous schedule and one sale transaction for the full amount of the new schedule/ product.

If No is selected and the customer replaces a schedule (upgrades or downgrades), he or she will simply see the new sale transaction on his/her card or bank account statement. The residual portion of the previous schedule is not refunded.

If No is selected and the customer cancels a schedule/subscription, no refund of residual funds is given. However, the effective date of the cancellation can be set to “end of cycle” so that the customer continues to receive the service/product until the end of that billing cycle.

Process Residual with Post Pay scenario Selecting Yes means that a customer will be charged for any residual amount remaining for an existing schedule when that schedule is cancelled or replaced. The customer will see a charge on his/her card or bank account statement. Note: If the customer replaces an existing schedule with a different product

(i.e., upgrades or downgrades), he/she will see two transactions on his/her statement—one charge transaction for the residual value of the previous schedule and one sale transaction for the full amount of the new schedule/ product.



Page 11 of 111


If No is selected and the customer replaces a schedule (upgrades or downgrades), he or she will simply see the new sale transaction on his/her card or bank account statement. The customer is not charged for the residual portion of the previous schedule.

If No is selected and the customer cancels a schedule/subscription, the customer is not charged for the portion of the service he or she has used. In addition, the effective date of the cancellation can be set to “end of cycle” so that the customer continues to receive the service/product until the end of that billing cycle without being charged.

3.4.1.3 Trial Periods Customers signing up for products that require recurring billing can be offered a trial period in the Payment Portal and the Gateway. Please see the relevant sections in the Portal User Manual and the iPAY Gateway API Guide to find out how to set up trial periods.

Table 4 - Maximum Trial Period Lengths

For a Frequency Type of … … the Trial Period (Frequency Interval) cannot exceedDAILY 90

WEEKLY 4MONTHLY 6YEARLY 1

All recurring transactions must be submitted with a start date. This is the date when the customer begins to receive the product or service. In addition, most recurring transactions must also include a charge date, which is when the customer is first charged for the product or service. However, if a trial period is included in the product or service the customer purchases, the Gateway system calculates the first charge date based on the start date and the duration of the trial period.

3.4.1.4 Trial Amount An amount can be specified for the trial period. If no amount is specified, then it is assumed the trial period is free.

3.4.1.5 Initial Amount If you have a special introductory price for the first billing cycle of your product, you can submit an Initial Amount for that customer in the Payment Portal or through the Gateway. This amount is only applied to the first billing occurrence.

3.4.1.6 Retry Function The gateway recurring engine will resubmit failed billing attempts according to the retry parameters set by the merchant at the schedule or billing template level. However, the transaction can only be retried for failures that are considered recoverable. In many cases, failed transactions cannot be resubmitted due to association regulations. The table below shows the authorization response codes (ARCs) for which transactions can be resubmitted. If a transaction fails with an ARC not shown below, it will not be resubmitted.

See the following page for a table of recoverable ARCs.



Page 12 of 111


Table 5 - Recoverable ARCs

ARC RESPONSE TEXT 03 TERM ID ERROR 05 DECLIN E 06 ERROR 12 INVALID TRANS 13 AMOUNT ERROR 14 CARD NO. ERROR 15 NO SUCH ISSUER 19 RE ENTER 25 NO RECORD FOUND 27 ERROR 28 NO REPLY 30 CALL 51 DECLINE 54 EXPIRED CARD 61 DECLINE 65 DECLINE 76 NO ACTION TAKEN 77 NO ACTION TAKEN 78 NO ACCOUNT 81 ENCRYTPION ERROR 91 NO REPLY 92 INVALID ROUTING 94 DECLINE 96 SYSTEM ERROR N0 FORCE STIP N4 DECLINE TO TIME OUT XA FORWARD 2 ISSUER XD FORWARD 2 ISSUER Z3 UNABLE TO ONLINE



Page 13 of 111


3.4.2 Recurring Billing Scenarios Below are graphics showing various events for recurring transactions for several different scenarios.

Figure 2 - Recurring Scenarios (Post-Pay)



Page 14 of 111


Figure 3 - Recurring Scenarios (pre-pay)



Page 15 of 111


3.5 Repository Transactions In March 2006, repository transactions were added to the Gateway system. The purpose of these transactions is to provide structures in which data can be stored, referenced, and retrieved.

Table 6 - Transaction Definitions for Repository


REPOSITORY PRODUCT INSERT A PRODUCT insert creates a set of data that can be referenced in a TEMPLATE (see next section)

REPOSITORY PRODUCT MODIFY The MODIFY transactions allows the modification of a single or multiple fields to the PRODUCT record.

REPOSITORY PRODUCT DELETE This transaction will delete the PRODUCT record. A PRODUCT cannot be deleted if it has any associated billing templates. All templates must be deleted before the PRODUCT can be deleted.

Currently, PRODUCTs can be referenced in TEMPLATEs, and TEMPLATEs, in turn, can be used to build recurring schedules with a minimum of XML fields if you are programming directly to the gateway. See the sample XML transactions in the iPAY Gateway API Guide.

3.6 Template Transactions In March 2006, template transactions were added to the gateway system. The purpose of these transactions is to provide structures in which data can be stored, referenced, and retrieved.

Table 7 - Transaction Definitions for Template


TEMPLATE BILLING INSERT A TEMPLATE insert creates a set of data that can be referenced in a SCHEDULE.

TEMPLATE BILLING MODIFY The MODIFY transactions allows the modification of a single or multiple fields to the TEMPLATE record.

TEMPLATE BILLING DELETE

This transaction will delete the TEMPLATE record. A billing template cannot be deleted if it has any associated active schedules (i.e., schedules that are still actively billing customers). All schedules must all be inactivated (i.e., canceled/deleted) before a billing template can be deleted.

Currently, TEMPLATEs can be referenced in SCHEDULES, which allows the building of recurring schedules using a minimum of XML fields if you are programming directly to the gateway. See the sample XML transactions in the iPAY Gateway API Guide.

The BILLING service type is used to set up the parameters for a merchant’s recurring billing cycle(s). Merchants can have N number of unique billing templates, and each billing template can be referenced by N number of individual customer schedules.



Page 16 of 111


4. Credit Card TransactionsFor definitions of credit card transactions, see Table 1 and Table 3.

4.1 Transaction Request Process—iPAY Gateway System A real-time transaction request is achieved by sending a single request through an Internet connection. Transaction responses are generally returned in 1–3 seconds, depending on your Internet service provider.

The merchant submits credit card transactions to Planet Payment Processing via a socket connection through the Internet.

1. The Planet Payment Processing firewalls allow the transmission of transactions and directthem to our internal switches, which load balance the incoming transactions to thepayment server with the least activity.

2. The payment server decrypts and validates the transactions using the merchant’sprocessing and setup information stored in an XML file. The Data Publisher publishes thisfile daily at 12:00 AM (GMT) from the database.

3. Transactions that cannot be decrypted or validated or those that we cannot deliver asuccessful response for are known as invalid transactions. Invalid transactions arereturned to the merchant and are not recorded in the database. No other parties areinvolved.

4. Valid transactions that require an authorization (Authorization, Sale) from the credit cardissuing bank are sent to a service provider via dedicated communication lines. The serviceprovider sends the transaction response back to the gateway. The gateway sends theencrypted authorization response back to the merchant on the same connection within 1–3seconds, depending on your Internet service provider.

5. Valid transactions that do not require an authorization (Capture, Refund, Void) arereturned to the merchant. No other parties are involved.

6. Transactions are then written to the database in a pending status until they are picked upby the settlement process, which moves the transaction’s funds.

4.2 Transaction Requirements—iPAY Gateway System The matrix below shows the valid combinations of some required fields for credit card transactions. Note: Based on transaction type and underwriting requirements, some additional fields need to

present during processing. For more information about required fields, please see the iPAY Gateway API Guide.



Page 17 of 111


Table 8 - Business Logic Matrix for Credit Card

ENTRY_MODE TRANSACTION_ID

Required? TRANSACTION_

INDICATOR SERVICESERVICE

TYPE SERVICE SUBTYPE

SERVICE FORMAT DESCRIPTION OF WHEN USED

CC DEBIT AUTH 3 No 7 CC DEBIT AUTH 1010 E-commerce

3 No T CC DEBIT AUTH 1010 Telephone order

3 No 2 CC DEBIT AUTH 1010 Recurring

3 No M CC DEBIT AUTH 1010 Mail order

3 No 5 CC DEBIT AUTH 1010 Verified by Visa transactions only

3 No 6 CC DEBIT AUTH 1010 Verified by Visa transactions only

2 No NA CC DEBIT AUTH 1020 Key entered

1 No NA CC DEBIT AUTH 1020 Swiped








CC DEBIT CAPTURE W/ TRANSACTION ID NA Yes NA CC DEBIT CAPTURE 1010

Transaction ID will retrieve the previous value submitted in the original transaction

NA Yes NA CC DEBIT CAPTURE 1020NA Yes NA CC DEBIT CAPTURE 1021 NA Yes NA CC DEBIT CAPTURE 1022NA Yes NA CC DEBIT CAPTURE 1030NA Yes NA CC DEBIT CAPTURE 1070

CC DEBIT CAPTURE 3 No 7 CC DEBIT CAPTURE 1010 E-commerce

3 No T CC DEBIT CAPTURE 1010 Telephone order

3 No 2 CC DEBIT CAPTURE 1010 Recurring

3 No M CC DEBIT CAPTURE 1010 Mail order

2 No NA CC DEBIT CAPTURE 1020 Key entered

1 No NA CC DEBIT CAPTURE 1020 Swiped








CC DEBIT SALE 3 No 7 CC DEBIT SALE 1010 E-commerce

3 No T CC DEBIT SALE 1010 Telephone order

3 No 2 CC DEBIT SALE 1010 Recurring

3 No M CC DEBIT SALE 1010 Mail order

CC DEBIT SALE, continued



Page 18 of 111


ENTRY_MODE TRANSACTION_ID

Required? TRANSACTION_

INDICATOR SERVICESERVICE

TYPE SERVICE SUBTYPE

SERVICE FORMAT DESCRIPTION OF WHEN USED

3 No 5 CC DEBIT SALE 1010 Verified by Visa trans only

3 No 6 CC DEBIT SALE 1010 Verified by Visa trans only

2 No NA CC DEBIT SALE 1020 Key entered

1 No NA CC DEBIT SALE 1020 Swiped








CC CREDIT REFUND W/ TRANSACTION ID

NA Yes NA CC DEBIT REFUND 1010

Transaction ID will retrieve theprevious value submitted in theoriginal transaction






CC CREDIT REFUND 3 No 7 CC DEBIT REFUND 1010 E-commerce

3 No T CC DEBIT REFUND 1010 Telephone order

3 No 2 CC DEBIT REFUND 1010 Recurring

3 No M CC DEBIT REFUND 1010 Mail order

2 No NA CC DEBIT REFUND 1020 Key entered

1 No NA CC DEBIT REFUND 1020 Swiped








KEY: ENTRY_MODE 1 = A card reader swiped the data (track data must be present)

2 = Data was key entered, card present 3 = Data was key entered, card not present

TRANSACTION_ INDICATOR

M Mail Order T Telephone Order 2 Recurring 5& 6 VERIFIED BY VISA 7 One Time or Recurring Secure



Page 19 of 111


4.3 Transaction Overviews Figure 4, Figure 5, and Figure 6 give overviews of the authorization, settlement, and chargeback processes for credit card transactions. Figure 4 - Overview of Credit Card Transaction Flow: Authorization Process



Page 20 of 111


Figure 5 - Overview of Credit Card Transaction Flow: Settlement Process



Page 21 of 111


Figure 6 - Overview of the Credit Card Chargeback Process



Page 22 of 111


4.4 Merchant Responsibilities for CC Transactions This section describes the merchant’s basic responsibilities for credit card transactions as well as the minimum data requirements for credit card receipts. For definitions of valid transaction types for credit cards, see Table 1.

4.4.1 Basic Transaction Requirements For all credit card transactions, the merchant must: Be specific when describing the merchandise or service being purchased. This

reduces the opportunity for the cardholder to charge back the sale. (Example: “Item number 1234 – blue dress”; not just “Item number 1234”)

Deliver the product or service at the time of the sale unless otherwise agreed upon inwriting by the cardholder and the merchant.

Fully disclose the refund policy on the receipt or in a readily visible area.

4.4.2 Merchant Responsibilities for Sales Transactions The processing requirements for sales transactions are based on the merchant category code and how the cardholder information is obtained and processed between the cardholder and the merchant. Card security validation procedures, cardholder verification procedures, and an imprint of the card (if it is a card-present transaction) must be obtained any time the cardholder’s card cannot be electronically read into the merchant device, regardless of the card presence at the time of the sale. These requirements help reduce the chargeback liability and, in some cases, qualify the transaction for a better discount rate.

4.4.3 Credit Card Sales Receipt Data Requirements For every completed authorized transaction, a receipt must be made available to the cardholder either automatically or upon the cardholder’s request.

For every completed authorized e-commerce transaction, a receipt page must be displayed after the cardholder confirms a purchase. The display of the receipt on the screen must be printable.

If a transaction receipt is produced following an unsuccessful transaction attempt, the receipt must contain the response or failure reason, in addition to all other required information as specified below.

The merchant must make sure that all copies of the sales receipts are complete and legible.

Card-present POS receipts must include the following: Transaction date Transaction time Transaction amount (including applicable tax and tip) Transaction type (sale, refund, etc.) Transaction indicator (mail order, telephone order, etc.) Transaction result AVS and CVV results Legal merchant name Merchant location (complete address) Merchant phone number Merchant ID Card type



Page 23 of 111


Card number (must be truncated to show no more than the last five digits) Purchaser name and complete address Auth/Approval code Cardholder name as it appears on the card Signature line and cardholder’s signature. The cardholder must sign the sales receipt

in the presence of the merchant. The cardholder’s signature on the sales receiptmust match the signature on the back of the card.

Account type selected (if applicable)Receipts for card-not-present transactions must include the above information as well as Merchant’s URL “Card Not Present” must be printed or written on the signature lineThe return/refund policy must be provided on each copy of the sales draft one-quarter inch above or below the cardholder’s signature to avoid liability for chargebacks. Below is recommended wording for disclosure of your refund policy. 1. NO REFUND. The merchant does not accept merchandise return or exchange and

may not issue a refund to a cardholder. 2. EXCHANGE ONLY. The merchant only accepts merchandise for immediate

exchange for similar merchandise of a price equal to the amount of the original transaction (include any time restrictions).

3. IN-STORE CREDIT ONLY. The merchant accepts returned merchandise and willoffer the cardholder an in-store credit for the value of the merchandise returned for use only in the merchant’s place of business (include any time restrictions).

4. REFUND WITH RECEIPT ONLY within X days from date of purchase.

As of December 1, 2006, the Federal Trade Commission (FTC) requires that card expiration dates must be completely masked or omitted from the customer’s receipt. The above requirements apply only to electronically printed receipts, not to handwritten or imprinted ones, and they apply only to receipts given to the customer, not to any transaction record merchants may retain. However, it is recommended that any receipts you keep do not contain complete card numbers or unmasked expiration dates. Remember that you are responsible for protecting cardholder information. The less confidential information you keep, the less risk you have of compromising sensitive cardholder data.

4.5 Card Security Validation Procedures (Card Present) The merchant must: Verify that the expiration date is valid. Do not accept a card that is past its expiration date. Inspect the card for alterations or signs of counterfeiting. Verify that there is a signature on the signature line on the back of the card and verify that

the name on the back of the card matches the name embossed on the front of the card.Request additional photo identification to validate that the name of the person using the cardis the same as the cardholder name on the card.

Compare the cardholder’s signature on the sales slip to the signature on the back of thecard.

Verify that the number embossed on the front of the card matches the number on thesignature line and the magnetic strip.



Page 24 of 111


4.6 Cardholder Verification Procedures (card not present) A number of procedures can help to verify the cardholder’s identity. Implementing any of the following methods can help you reduce fraud and chargebacks.

4.6.1 CVV Card verification value (CVV) is an extra level of cardholder validation and is part of the authorization process. It is especially useful for card-not-present transactions. The CVV is printed on the card (as opposed to being embossed). It is not encoded on the magnetic strip. The value is 3 digits for Visa, MasterCard, Diners Club, and Discover; it is 4 digits for American Express. See the iPAY Gateway API Guide for detailed information on this data field.

Note: These values are not permitted to be stored anywhere and are available for real-time transactions only. Storing CVV data is a violation of card association rules and regulations.

How Does CVV Work? When merchants ask customers for their account numbers, and the CVV information is in the authorization messages, the Issuers can validate the CVV code and send the match/no-match results in their authorization responses. Merchants, by using the CVV results along with the address verification services (AVS) and authorization responses, can then make more informed decisions regarding the acceptance of transactions.

Where are the CVV values located? The CVV three-digit values are printed on the signature panel on the back of most Visa and MasterCard credit cards, immediately following the credit card account number. For American Express cards, the four-digit code is called the card identification (CID) number and is printed (not embossed) on the front of the card.

Location of CVV for Visa and MasterCard cards

Location of the CID number on American Express cards

How does CID work for American Express? If merchants want to be able to use the American Express CID as an additional layer of verification, they must enroll with American Express to have this function activated. If you pass in CID values without being enrolled, the CID number will not be validated. See Section 4.6.2 for enrollment information.



Page 25 of 111


What should I do if the issuing bank approves the transaction but the CVV response is not approved? The gateway system does not validate the CVV data—it only verifies the presence of the data within the required fields. Merchants should be aware that not all issuing banks decline a transaction based on an invalid CVV response. For most cards, the merchant is responsible for reviewing and approving transactions that are approved by the Issuer but have an invalid CVV response.

Note: Depending on your merchant agreement, you may need a valid CVV response to process all transactions.

The Payment Portal and the iPAY Gateway system can allow merchants to control whether they wish to accept transactions that failed the CVV check but otherwise were approved by the card Issuer. The gateway system only validates these transactions when an ARC code of 00 (approved) and a CVV response from the Issuer are returned in the authorization response.

In the Payment Portal, the CVV validation settings are selected in the Terminal. The choices in the drop-down list are exact or none. If the merchant selects exact, then the gateway system will evaluate the CVV response from the issuing bank. If the CVV response indicates an exact match of the CVV data, the transaction is allowed to proceed. If the CVV response shows that the CVV data have not passed the validation at the issuing bank (but the transaction is otherwise valid), then the gateway system will decline the transaction on behalf of the merchant, and the merchant will receive an Authorization Response Code (ARC) of SD for soft decline.

Note: In some cases, the CVV data cannot be processed. In these cases, the validation described above is bypassed and the transaction is allowed to proceed. (This occurs when the CVV response value is P, S, or U.)

If the merchant selects none, then the gateway system will allow all approved transactions to proceed, without considering the CVV response from the issuing bank.



Page 26 of 111


4.6.2 Enrolling in CID American Express offers a security feature on all American Express® Card products called a Card Identification (CID) number. The CID is the four-digit number printed on the front of the card and is used for verification and validation in situations where a card is not present (such as purchases made over the phone or by mail). It is used to prove that the card member is holding the actual card. Since this number is not printed on receipts, it's virtually impossible to replicate accurately on counterfeit or altered plastic.

To validate American Express cards using the CID number, merchants must first be activated in the American Express CID program. Follow the steps below to request activation.

1. E-mail the request to the following address: [email protected] e-mail must contain the following information: Your American Express Merchant Number Your Merchant Name Your Merchant Address Your Contact Name Your Contact Phone Number Third Party Processor – Planet Payment

2. American Express Merchant Services Fraud Prevention assesses the merchant'seligibility and replies to the original e-mail request in three to seven business days.

3. Depending on eligibility requirements, the merchant may need to perform one ormore of the following: Consult with an American Express Network Development Consultant (NDC), Complete a Site Certification, and/or Provide screen shots of his/her Web page to American Express Merchant

Services Fraud Prevention. Return an original, signed CID contract addendum to American Express

Merchant Services Fraud Prevention. (Contract Addendum will be provided tomerchant for signature once CID eligibility is determined.)

4. American Express activates the merchant within three to five business days afterreceiving all required documentation.

Note: The total time to activate the Merchant for CID averages ten business days; however, the process depends on how quickly the Merchant completes and returns the required information.



Page 27 of 111


4.6.3 AVS Address verification system (AVS) is part of the credit card authorization process. The cardholder’s billing address is validated with the card Issuer to help the merchant identify fraud. During authorization, an AVS code (AVS_RESPONSE) is returned along with the authorization code; the AVS code indicates the level of accuracy of the address match. Though the credit card transaction may have been approved, the merchant can decide whether to accept the sale based on the AVS response.

For example, a merchant may decide (for fraud prevention purposes) only to ship product to customers whose transaction received a positive AVS response. Note that some Issuers do not support AVS. There are currently three levels of AVS requirements based upon the merchant profile; only the ADDRESS and POSTAL_CODE fields are validated during this process. Required data vary depending on your merchant profile settings. AVS data are not required for a card-present transaction where the credit card information was electronically read (i.e., swiped).

Table 9 - AVS Data Requirements

AVS Level Required Data* None No AVS data are required Partial ADDRESS and POSTAL_CODE

Full FIRST_NAME, LAST_NAME, ADDRESS, CITY, STATE, and POSTAL_CODE Default setting for SERVICE_FORMAT 1010

* Although ACH transactions do not validate these data, these fields will be required based on theAVS settings as defined by the iPAY Gateway system.

See the iPAY Gateway API Guide for a full description of the data fields.

Example 1: 100 West Commons, Blvd., Suite 200 New Castle, DE 19720

The address field contains the numeric characters 100200; AVS uses the first five numeric characters or ‘10020’. AVS will read all numeric characters in the postal code field.

Note: If a cardholder tells you that his or her street address number is spelled out, you still may want to enter it as numeric digit(s) unless the cardholder is absolutely sure of how the address information appears on his/her billing statement.

An address may be entered in many different ways, depending on how the data are entered at the issuing bank and at the merchant location. Therefore, AVS is not 100% accurate.

Example 2: One Corporate Commons, Suite 200 100 West Commons, Blvd. New Castle, DE 19720

An issuing bank may have recorded the cardholder’s address as shown in Example 1. If the merchant enters the address in Example 2, the AVS will respond with a postal code match (Z), but not an exact match (Y) on the address and postal code.



Page 28 of 111


4.6.3.1 Using AVS The AVS_RESPONSE does not determine the success of a transaction (approval or decline). Because of this, the merchant will need to run a series of transactions to fully utilize the AVS service. First perform an AUTH transaction; if the AVS matches your criteria, then follow up with a CAPTURE. If the CAPTURE is not performed, the customer will not be billed, and the authorization will drop from the cardholder’s account in 7–10 days. This method would freeze the entire AUTH amount from the cardholder’s open-to-buy limit.

What should I do if the issuing bank approves the transaction but the AVS response is not approved? The gateway system does not validate the AVS data—it only verifies the presence of the data within the required fields. Merchants should be aware that not all issuing banks decline a transaction based on an invalid AVS response. The merchant can review the response and decide whether to proceed with transactions that are approved by the Issuer but have an invalid AVS response. Merchants can also set up controls in the Payment Portal or in the gateway to automatically handle this decision. See below.

Note: Depending on your merchant agreement with Planet Payment and the sponsored banks, you may need a valid AVS response to process all transactions.

The PS Portal and iPAY Gateway system include functionality that allows merchants to tell the gateway system how to handle transactions that failed the AVS check but otherwise were approved by the card Issuer. The gateway system only validates these transactions when an ARC of 00 (approved) and an AVS response are returned in the authorization response.

The table below shows which transactions would proceed through the system based on the AVS (consumer) validation selection made by the merchant (in the Terminal of the PS Portal) and the returned AVS response.

Table 10 - AVS (Consumer) Validation Summary

Validation selected by merchant

Definition AVS response(s) from card Issuer that result in a validated transaction in the

gateway system ADDRESS Street address only X, Y, A, B, D, F

EXACT Street address and postal code X, Y, F

ANY Street address or postal code X, Y, W, Z, A, B, D, P

NONE No match required All codes are accepted and the transaction will proceed POSTAL Postal code only X, Y, W, Z, P, F

If a transaction fails the validation, the transaction is declined by the gateway system and an Authorization Response Code (ARS) of SD (soft decline) is returned to the merchant.

If the AVS response is C, E, G, I, R, S, or U, the validation described above is bypassed and the transaction is allowed to proceed.



Page 29 of 111


4.6.4 Verified by Visa and MasterCard SecureCode Verified by Visa and MasterCard SecureCode help to protect a cardholder’s bankcard by requiring the cardholder to enter a personal identification number (PIN) or password (of his or her choosing) when completing an e-commerce transaction. Not every issuing bank offers these programs; the bankcard Web sites list which issuing banks participate.

Not only do these programs help to protect cardholders from fraud or unauthorized use of their bankcard, the additional authorization data and authorization approval protect merchants from “cardholder non-authorization” chargebacks.

Typically, the following parties are involved in transactions involving Verified by Visa or MasterCard SecureCode: Merchant Processor (Planet Payment) Authentication vendor—this is the vendor that will provide the merchant with the

programming for their Web site to ask the cardholder for their Verified by Visa orMasterCard SecureCode information. They are also coded to the Third-Party PINRepository in accordance with MasterCard’s and Visa’s specifications.

Third-Party PIN Repository—this group stores all PIN and password information forMasterCard and Visa.

4.6.4.1 How it WorksDuring an e-commerce transaction, the cardholder enters additional authenticationinformation, which is transmitted directly to the authentication vendor.Note: The merchant never sees the cardholder’s password or PIN, and that

information never goes through the merchant’s system—it is all handled by the authentication vendor, the PIN repository group, and the processor. The only thing the merchant will see is the response code.

The authentication information travels from the authentication vendor to the PIN repository group, who will check the data and return a response of “passed,” “failed,” or “system unavailable.” This information is passed to the authentication vendor, who then passes it to the merchant. If the authentication passed, the transaction is completed. The merchant can choose to abort or complete transactions with a response of “system unavailable,” but the merchant will retain chargeback liability if he or she chooses to complete transactions with this response. The merchant must include the authentication response codes when the transaction data are sent to the processor. The processor will send the Verified by Visa and MasterCard SecureCode information to Visa and MasterCard, respectively, when the transactions are processed. To get set up, merchants must technically integrate and certify with an authentication vendor. In addition, the authentication vendor must register with Planet Payment’s sponsoring banks. The authentication vendor is responsible for its integration with the Third-Party PIN repository group. Merchants must also notify us so that we can make the necessary changes to the merchant’s profile in our system. If a merchant sends Verified by Visa or SecureCode response code data to our system without notifying us first, the transactions will fail, and the merchant will receive an MRC of IS for “inactive service.”



Page 30 of 111


Finally, Merchants must add extra fields and include the authentication response codes with the data they send to the gateway. See the iPAY Gateway API Guide, Version 2.0 or higher. Detailed information can be found in the bankcard associations’ implementation guides.

4.6.5 3D- Secure – 3-D Secure offers an added layer of security for online credit and debit card transactions, validating that the online shopper is actually the cardholder. It enables cardholders to create a PIN, or ‘secure code,’ and assign it to their credit card. During checkout, the customer is prompted to enter their credit card PIN. The cardholder’s identity can then be confirmed by their credit card provider.

3-D Secure adds another authentication step for online payments. Merchants are encouraged to use 3-D Secure to achieve higher coverage against fraud losses. When a merchant does not use 3-D Secure they are liable for fraudulent transactions even if the transaction was properly authorized. Cardholders who aren’t enrolled in 3D Secure will not notice any change to their transaction process.

4.7 Merchant Responsibilities for Credit Card Refund Transactions The merchant must observe the following rules for refund transactions: Cash refunds are not permitted on credit card sale transactions. Always refund against the credit card that the sale was processed on. The amount of the refund cannot be more than the original sale transaction. Process the refund immediately to avoid chargebacks for no refund issued. For an even exchange

o The merchant does not need to prepare a new sales receipt or a credit receipt. For a return for credit only

o The merchant should prepare a credit receipt with complete information (just like salesreceipt) for the full amount of the sale, including tax.

For an exchange for a greater or lesser valueo The merchant should prepare a credit receipt for the full amount of the original sale,

including tax. The merchant should then prepare a new sales receipt for the full amountof the new purchase.

4.7.1 Sales Receipt Data Requirements for Credit Card Refunds The receipt requirements for a refund are the same as for a sale. Please see Section 4.4.3.

4.8 Other Functionality Highlights 4.8.1 The iPAY Gateway TRANSACTION_ID In the gateway system, a unique identifier is generated and returned by the gateway for each transaction. This is the TRANSACTION_ID, and it is used to match transactions (e.g., AUTH to a CAPTURE or SALE to a VOID).

If you perform a separate AUTH and CAPTURE, the CAPTURE transaction must include the TRANSACTION_ID from the original AUTH transaction. This allows certain fields to be pulled from the original AUTH transaction and appended to the CAPTURE transaction. Including these authorization addenda records with the CAPTURE transactions allows you to receive the best processing rate.

If you do not include the original TRANSACTION_ID with your CAPTURE transactions, the transactions will downgrade to the most expensive rate.



Page 31 of 111


You can submit CAPTURE transactions without an original TRANSACTION_ID if the authorization was a voice AUTH or if the authorization was given by a service provider other than Planet Payment. However, you will not receive the best processing rate for these transactions.

The original TRANSACTION_ID must also be included with VOID and REFUND transactions.

4.8.2 Merchant Descriptor Merchants who are not registered with Visa as an Internet Payment Service Provider (IPSP) merchant can send a merchant descriptor (in the form of XML tags) to override the settings in the merchant profile (CIP). This would allow different data (such as a different customer service phone number, depending on the type of goods purchased) to be shown on the cardholder’s statement.

The Merchant Descriptor XML tags include MERCHANT_NAME, MERCHANT_PHONE, MERCHANT_STATE, MERCHANT_CITY, and MERCHANT_URL. Only the first two could appear on the cardholder’s statement, depending on your service provider. The other fields, MERCHANT_STATE, MERCHANT_CITY, AND MERCHANT_URL, can be used for internal reporting, if desired. See the iPAY Gateway API Guide for information on these data fields.

If the merchant is using the TRANSACTION_ID functionality, then the incoming merchant descriptor data XML tags are ignored and the merchant descriptor data from the referenced transaction are used.

If the merchant is a not an IPSP merchant and the TRANSACTION_ID functionality is not used, then the values for MERCHANT_NAME and MERCHANT_PHONE in the message request are stored in our database and are used in the cardholder’s statement, if permitted by the service provider. IPSP merc

ipay business logic guide - planet · ipay business logic guide. gateway specification. version...

Documents