General Payments Information

The following diagram illustrates the POPs and the integration points to the On-Demand services.

There are features that can be used at authorization (when you are reserving the funds for the purchase) to deter fraudulent orders. It is applicable for MOTO and eCommerce Transaction Types. For retail transactions, the card is swiped and the appropriate information is obtained and verified from track data on the card. For eCheck transactions, there are various requests made during authorization for fraud management purposes that vary by processor.

Following are the fraud management capabilities supported by Paymetric. Note that support of these features is dependent upon your chosen processor. See the Processors (Cartridges) section for more details.

CVV, CVV2, CVC or CID Code

Used to reduce merchant risk in Card-Not-Present transactions like eCommerce (Internet) or MOTO (telephone or mail order). It is a three or four digit value which provides your payment processor with a cryptographic check of the card's authenticity. The terminology for these codes differs based on the card type. The terms are generally used interchangeably but are commonly all referred to as CVV. Visa, MasterCard, American Express and Discover all have a version of the Card Verification functionality to add assurance that the consumer placing the order has access or physical possession of the credit card itself in order to use the CVV code.

• CVV, CVV2 – Card Verification Value for Visa®

• CVC – Card Validation Code for MasterCard®

• CID, 4DBC – Card Identification number for American Express and Discover

Where can I find my CVV/CVC/CID Number?

Card type	Name	Location
Visa	Card Verification Value (CVV2)	Three digits to the right of the credit card number in the signature area on the back of the card.
MasterCard/Eurocard	Card Verification Code (CVC2)	Three digits to the right of the credit card number in the signature area on back of the card.
Discover	Card Identification Number (CID)	Three digits to the right of the credit card number in the signature area on back of the card.
American Express	Card Identification Number (CID or 4DBC)	Four digits printed (not embossed) on the front of the card above the credit card number.
Diners Club	Card Verification Value (CVV2)	Three digits to the right of the credit card number in the signature area on the back of the card.

These values are passed during the authorization and used in validations. No merchant, gateway, nor processor is allowed to store these values per PCI-DSS regulations.

Verification Values and Codes

The number is printed only on the credit card - It is not contained in the magnetic stripe information, nor does it appear on sales receipts or statements. Using the Card Verification Values (CVV, CVV2) and Card Verification Codes (CVC, CVC2)/CID value can help minimize the risk of unknowingly accepting a counterfeit card or being a victim of fraud. For added security, the Merchant is not allowed to store the CVV value.

Note: The presence of the CVV functionality does not necessarily result in a hard authorization decline when there is a CVV mismatch. It is typically only informational, so the decision to ship the product in spite of a mismatch is at the discretion of the merchant.

We recommend:

Reviewing the Credit Card companies publications concerning the Cardholder Information Security Program (CISP) regulations

These regulations, to which a merchant is bound, detail significant penalties for violating the CVV restrictions, and are similar across Visa, AMEX, Discover and other credit card companies.

The business logic about retaining the CVV value for subsequent authorization attempts is understandable, but the fact that you will be FINED for storing the value negates this argument. Most clearinghouses will tell you themselves that storing a CVV value is:

• A violation of your merchant agreement

• Will subject you to fines

• Is not required for subsequent authorizations because providing it in automated subsequent authorizations indicates you’ve violated merchant processing rules by storing it in your system

To engage this functionality in your XiPay implementation will require additional configuration and licensing and likely an amendment to your merchant agreement. Please contact your account representative for details.

Address Verification

The Address Verification System (AVS) is one of the many anti-fraud steps you as a merchant and the banks can take when processing credit card transactions. Credit card issuers use this service to verify the card-holder by the address given. It was originally intended for mail-order companies, so they would know for sure that they were sending the product to the card-holder. This system is also used for service and subscription based industries to help prevent someone from using another person's credit card number fraudulently.

The issuing bank determines what if anything will be validated in the address check. Address verification is typically done by scanning the address data within the variables sent and checks the 5 or 9 digit zip code along with the first five numeric characters of the street address. AVS does not perform any alpha to numeric conversions. This means an address entered as 'One Main Street' will return a negative AVS result code. If the address had been entered as '1 Main Street' the address match would have been successful.

Note: AVS does not necessarily guarantee a non-fraudulent sale - it is typically a secondary feature done after the approval and is designed for informational use only. In this case, it is the responsibility of the merchant to accept (ship) or decline (not-ship) a transaction.

Paymetric has no role or control on what is checked or when a response is returned, we just pass the data. You will need to contact your processors for specific information on what is checked or when a response is returned.

Consider the following when implementing AVS:

• AVS is a service that must be engaged with your processor

• Depending on the Cartridge you are utilizing, there may be configuration settings required

• There could be restricted characters to be aware of in the address field.

• You should consult your processor for a list of the AVS response codes and their meaning

• For SAP customers, the address always sent from SAP is the full Payer Partner address

The result of an AVS failure may differ depending on the processor (e.g. Hard Decline = Auth is declined and Halts the order fulfillment process or Soft Decline = auth is still successful and Merchant is advised of failure but transaction is approved; shifts the “order fulfillment” responsibility to the merchant) Post Auth userexit code may be needed if you desire a different outcome on the soft decline.

Paymetric Consulting Services is available to assist with an AVS implementation.

MasterCard® SecureCode™ (MCSC) / Verified by Visa™ (VBV)

These features establish a private code for a given MasterCard or Visa account that is used when making online purchases. When you correctly enter your SecureCode/VbV during a purchase at a participating online merchant, you confirm that you are the authorized cardholder and your purchase is then completed. If an incorrect SecureCode/VbV Code is entered, the purchase will not be completed. Even if someone knows the credit or debit card number, the purchase cannot be completed without the SecureCode/VbV Code at a participating merchant.

To engage card verification functionality in your XiPay implementation will require additional configuration and licensing and possible amendment to your merchant agreement. Please contact your account representative for details.

Refer to the following industry links for more information (links could change - search on card vendor websites for additional details):

http://usa.visa.com/personal/security/visa_security_program/3_digit_code.html

http://www.mastercard.com/us/merchant/security/what_can_do/beyond/index.htm

http://www.americanexpress.com/us/content/merchant/fraud-prevention/best-practices.html

http://www.discovernetwork.com/merchants/fraud-protection/prevention.html

Some processors have a flag that can be set at authorization to indicate the transaction is a recurring payment and may qualify it for lower interchange fees. See the Processors (Cartridges) section to see if your processor supports this feature. Your processor should provide interchange fee information.

A full reversal is essentially canceling or voiding an authorization transaction and if supported by the card issuer and the processor, releasing the hold on the funds. If performed from the XiPay WebGUI, it is the Cancel Authorization Operation. This sets the transaction status to 500 - Voided in XiPay and it will not be submitted for settlement. See the Processors (Cartridges) section to see if your processor supports this feature.

Paymetric has no control over when or if the authorized funds are released. The actual release of authorized funds is controlled by the card issuer. Paymetric only ensures the funds are not submitted for settlement if a void is properly processed meaning the transaction status has been set to 500 - Voided.

If XiPay has a problem connecting to the processor, the transaction will go into status -500 - Void Error. If for some reason the processor declines the reversal, the transaction will go into status -501 - Void. In either instance, the transactions will not be submitted for settlement. Both -500 and -501 indicate to XiPay that these transactions should not be submitted for settlement. You should contact your processor to let me them know of the reversal. As mentioned for the successful void status, the actual release of authorized funds is controlled by the card issuer. None of these void statuses is an indication that the funds have been released -- just that they will not settle.

A transaction can only be voided if it is in status 100 - Authorized, 101 - Authorized and acknowledged, or 110 - Authorized Sale. (Note that Authorized Sale status does not last long as transactions following this process are automatically captured and submitted for settlement by XiPay.)

Partial Reversals

A partial reversal occurs when a transaction is submitted at settlement for less than the authorized amount. If supported, this is performed automatically. See the Processors (Cartridges) section to see if your processor supports this feature.

A decline is when the issuing bank failed to approve the authorization. There are multiple reasons that a decline can occur. You can retry the card later; obtain a different payment card number from the customer; or perform various other options.

The processor or issuer should be contacted to ascertain the reason for an authorization decline.

Errors

Indicates there is a condition that prevents the submission to the processor or prevents the receipt of a valid response. For example, connectivity problem, invalid data, formatting problems, etc.

• Elavon viaConex – every hour x:50

• FDMS North – every hour x:00

• Amex CAPN – every hour x:10

• Paymentech Salem – every hour x:20

• Evalon Fusebox – every hour x:30

• All other processors: every 4-15 minutes

Additional features an also affect settlement submission times.

Settlement is usually triggered by the Merchant who first batches the transactions and then submits them; however, Paymetric has a couple of workflow options that allow XiPay to trigger settlement submission.

Settlement Sweeper (SS) is a configuration setting that can be requested by Merchants that want XiPay to manage their settlement batches or whose solution does not have the concept of batches. The transactions must be "captured" for settlement (either from the source system or using the Settle Operation in the XiPay WebGUI, then SS assigns batch IDs and schedules the batches for settlement.

If you are using the Sale Operation (see One-Step Authorizations table under XiPay WebGUI section for more details), then Auto-Capture (AC) must be configured. AC captures the transactions for settlement, assigns the Batch IDs and schedules the batches for settlement.

Following are the run-times for SS and AC. The transactions will then be submitted to the processor for settlement at the next processor-specific run-time schedule defined above.

• 3:00 am

• 11:00 am

• 8:00 pm

It is important that you perform daily reconciliation activities to ensure your settled batches were processed properly. You will want to first check B2B Payment's reports in the XiPay WebGUI to determine transmission status – determine if all transactions submitted without errors and are in a Complete status.

Next, you should compare settlement transactions from your system with the report from your processor and/or bank to ensure everything funded properly. Paymetric has no control over funding, only initial data validations and transmission of transactions.

• For SAP users – see the Reconciliation topic under the SAP section.

• For non-SAP users – your system administrator should provide you with instructions on reconciliation activities within your system.

• For both SAP and non-SAP users – see the Reports section under XiPay WebGUI. This topic introduces you to the reports and the information they contain.

When performing settlement for electronic payments, there are varying levels of data that you can provide as follows:

• Level 1 – Basic card data needed to authorize (reserve) the funds for the order.

• Level 2 – XiOptimize: Includes Level 1 plus purchase order number, sales tax, and invoice number; only applicable for corporate purchasing cards; you should review the appropriate data mapping spreadsheet for the Processor/Cartridge you are using for complete Level 2 field requirements.

• Level 3– XiOptimize: Includes Level 1 and 2 plus line item details for example: merchandise descriptions, quantity, item unit cost, UPC code, etc.; only applicable for corporate purchasing cards; you should review the appropriate data mapping spreadsheet for the Processor/Cartridge you are using for complete Level 2 field requirements.

Warning for SAP Implementations: Level 3 data will only be passed successfully from SAP if there is one and only one authorization per invoice. Because SAP has no standard way of enforcing this, it will be necessary to put business processes in place to enforce this requirement.

There are various processing fees associated with electronic payment processing. These rates vary based on the payment processing features that a merchant implements.

One method of reducing those costs is to provide additional levels of data for each order during settlement. The additional detail for the transactions reduces risk of fraudulent orders. Additionally, it provides more detailed reporting capabilities for the merchants and their customers.

The additional order details provided at settlement are referred to as Level 2 and Level 3 data (or Level II and Level III data). Based on the level of data a merchant provides for a given transaction during settlement, the processor determines if it qualifies for Level 2/3 processing and consequently the reduced processing fee.

Not providing the correct level of detail for a Level 2/3 transaction will result in one or more of the following depending upon your agreement with your processor:

1. The transaction fails during settlement which requires you to correct the data and resend.

2. The transaction is "downgraded", meaning that settlement processing will continue, but the transaction will be downgraded to the next level for which it qualifies and will result in the higher processing fee.

3. It can hinder reconciliation capabilities of the merchant's customers due to lack of data.

The following diagram illustrates the high-level workflow for authorization and settlement from the payment origination point to the On-Demand services.

1a	An order is entered via the Payment Origination Point (POP) – a web store or customer service representative's workstation or POS system. If you implemented Intercept, a token is generated before the order is submitted to XiPay On-Demand (OD).
1b	An order is entered via the Payment Origination Point (POP) – a web store or customer service representative's workstation or POS system. If you implemented Intercept, a token is generated before the order is submitted to XiPay On-Demand (OD).
2	If using Intercept, a token is returned and saved in the ERP or CRM system.
3	XiPay OD obtains authorization through the processor and then returns the authorization code in the Auth Response. If you have implemented any fraud management features (e.g. CVV, AVS) these are validated and confirmed in the Auth Response.
4	Submit settlement when ready. For SAP, perform settlement which communicates through PAS to XiPay to capture and submit transactions for settlement. Transaction status is first set to 200 when staged for settlement then 400 once settlement submission is complete. For non SAP, check with your system administrator on how to trigger settlement from your system(s) through XiPay. The transaction status is set to 200 first when they are staged (a.k.a. captured) for settlement. The transaction status is set to 400 once settlement submission is complete.
5	Settlement files are submitted to the processor based on a set schedule.
6	You can view transaction status and activity in XiPay WebGUI.