The latest release of the SDK for the 9.x branch is a good place to start. If you are interested using the 10.x branch or want more information about the differences between release 9.x and 10.x release please contact your Implementation Consultant, Relationship Manager, Partner Relationship Manager, or sdksupport.

Yes. The default will allow you to refund a transaction for more than the amount of the deposit. The ability to limit refunds is an option that must be requested per MID.

For a Deposit transaction, you would link it to the Auth by using the transaction ID returned in the corresponding Auth response. For a Refund you would use the transaction ID returned in the corresponding Deposit transaction.

No. We return the responses from the card networks and they do not reject auths based on address. We recommend that you review the auth responses for address mismatches to determine if you would like to proceed with a deposit.

Yes. The OrderSource Element is required for auth transactions.

You will need a new MID for foreign currency but the XML will remain the same. The MID will be set up to accept the currency that was specified so the XML would not need to change. You would only need to make sure you are sending to the correct MID.

Integration with us is very specific to each Merchant. What it really depends on is how fast you will be able to build your internal systems to integrate with us. The Implementation Consultant should be able to certify any transactions you send in a timely manner.

In order to have a test account set up with us, please provide your Implementation Consultant with a static IP you will be testing from. The Implementation Consultant will then set you up with a generic test account that you can request different features be turned on for. Typical turnaround for a test account to be set up is 1-2 business days after you have sent the static IP.

Absolutely, we are integrated with many different partners and gateways. If you are currently working with one or plan to, you can check with either your Sales Representative or Implementation Consultant to ensure we are integrated with them.

In order to connect to our system you must have a static IP. We are able to have a network range as long as that range is static as well. Without a static IP your IP may change causing your transactions to fail.

It is definitely possible to begin processing with us while utilizing a gateway or presenter to start and then code directly to us while you are processing live transactions.

Once you have completed the certification process, you will only need to certify for new transaction types. For example if you have tested and certified for Authorizations, Captures, Refunds, and Voids you can add a new division without needed to certify or test again for those transactions. If you wanted to add in Conditional Deposits, you will need to test and certify for that.

We will allow you to accept credit cards from any countries you would like. We do have features such as International Card Filtering and Issuer Country Indicator, which can filter out international cards or inform you of which country issued the card.

A batch of about 10000 transactions would take about 10 minutes to process.

You should be able to find sample XML in the XML Reference Guide. If you do not have our XML Reference Guide, either ask your Sales Representative, Implementation Consultant, or Customer Experience Manager for a copy of the most recent XML Reference Guide.

If you will be using a partner or gateway that is already directly integrated with us, you will not need to complete any certification testing. If you will be using a partner or gateway that is not integrated, they will need to perform certification testing.

The billing descriptor prefix is a visa requirement which helps your customers understand the charges on their statement. The prefix can be 3 or 7 characters and must be followed by an asterisk. After the prefix there is your usual billing descriptor. EX - ABC*ABC FIN CORP

Online is considered "real-time", while batch transactions are sent in a batch at the end of the day.

A $0 auth will confirm the card number exists, but does not prove that funds exist on the account. Not all card networks support $0 auths.

You may, but if you settle in USD, you must have both a US address and a US bank account.

This depends on the risk assessment that was completed as part of your onboarding process. Ask your CEM to confirm for you. Some merchants may be eligible for completely unrestricted descriptors, while others may have a more limited list they can choose from (depending on business need).

This will flag any transaction sent to us that is equal to or great than the amount you specify for the max transaction limit. This means your CEM will reach out to you to confirm whether or not you want to process the transaction in question. It is mainly used to prevent system errors from processing a transaction with an extra 0, for example.

The filter will automatically decline transactions based on whether or not the card is a pre-paid/reloadable card. The indicator returns information back to you to let you know the card is pre-paid, but does not make any determination beyond that (other than the result of the transaction request).

You should contact your CEM for questions related to your processing. They will be able to provide further information.

Please refer to section 1 of your contract for the funds transfer timeline.

Unlike Discover, Visa, and Mastercard, we cannot register you for American Express. You will need to contact them directly.

We take security seriously at Vantiv. If you believe you have discovered a vulnerability in our SDKs or any of our other products, please contact us immediately at security@vantiv.com. We appreciate you following the principles of responsible disclosure when reporting vulnerabilities to us.

If you are connecting directly: Merchant ID, Login, Password, Transaction URL If you are connecting via a 3rd party presenter: Merchant ID If you are connecting via Authorize.net: Terminal ID, Bank ID, Platform

In order for us to send out merchant-specific connection information, the merchant must have completed all of the requirements of the on-boarding process. This includes the profile setup (with implementations), the compliance review with our compliance team, and the risk assessment with our risk team.

In order to maintain the health and validity of the test environment we periodically wipe all data and rebuild with the latest configuration. While we do take steps to preserve and restore profiles, sometimes unforeseen circumstances require manual intervention for your connection to work. Please contact implementations@vantiv.com for more information.

It is recommended best-practice that you test normal transactions first to confirm connectivity before adding tokenization logic.

We will assist you in AU registration. Please contact your Customer Experience Manager or Implementation Consultant to get started. Once this has been completed (depending on the card networks this could take anywhere from 1-6 weeks) we will enable this feature for you.

This element should represent some methodology that will allow you to track the order in other systems you may use in your environment. There is no right or wrong answer to this, but it should be unique enough to identify each order.

US, Canada, and Great Britain only at this time.

We offers you a Virtual Terminal to allow you to manually enter transactions. You will need to provide us with a static IP address for the computer(s) you are designating as transaction entry machines.

We can support customer purchasing in any currency, but you may only settle in USD, AUD, GBP, JPY, Euro, CAD, and HKD.

You will always be able to change presenters or connection methods in the future. Please contact your CEM to get this change started at least 3-4 weeks in advance of any switchover.

The purpose is to prevent duplicate transactions from being processed. For online transactions, the system compares transaction type, the id attribute from the request, and the credit card number against other online transactions processed within the previous two days. The id element should be unique enough to catch duplicate transactions.

Please send the XML to your Implementation Consultant you have been working with and they will be able to determine the problem. If you have not been working with anyone contact your Customer Experience Manager for the next steps you should take.

First, ensure you are using the correct username and password. Your password for the test environment should begin with 'cert'. If that information is correct, confirm you are using the correct Merchant ID supplied by your Implementation Consultant. If you are still receiving the error, please contact your Implementation Consultant.

What we ask Merchants to test and certify for are any transactions you plan on potentially running in production. Typical transactions are Authorizations, Captures, Refunds, and Voids.

Custom Billing is an option Merchants have when sending transactions. This allows merchants to specify exactly what will show up on their customer's credit card statements. In order to use this, our Risk Department must approve the request. Please work with either your Sales Representative, Implementation Consultant, or Customer Experience Manager to put in that request.

A Conditional Deposit is one transaction that groups an authorization and a capture together. If the card is valid the capture will take place. Conditional Deposits will not fail is address or CVV does not match. An Authorization and Capture are two separate transactions. First the authorization is performed and depending on the response a capture can be performed on that authorization.

Yes all the XML Elements are case sensitive and you should follow the guide for the proper formatting.

In order to do address verification or check the CVV you will need to do an authorization transaction. Then look at the XML Response at the and XML elements. To find a list of AVS Response Codes and Card Validation Response Codes and their meanings please refer to the XML Reference guide under the section Payment Transaction Response Codes.

You should use the credit cards in the XML Reference guide to send test transactions. Our certification environment is not connected to the Credit Card Networks and therefor the responses you receive are coded to occur for the credit cards in the guide.

The reportGroup element defines how the transactions will show up in the Reporting UI. Depending on how you would like to group the transactions you send in will determine what you should send for the reportGroup element. While testing, it will not matter what you send; it is important for Live Production transactions.

Test cards are located in the Vantiv eCommerce XML Reference Guide_XMLx.xx_Vx.pdf in starting in section 2.4 Table 2-1

The test system will approve any credit card number that passes the credit card standard MOD 10 validation check. If you want to receive decline codes you must use the credit card numbers located in the Vantiv eCommerce XML Reference Guide_XMLx.xx_Vx.pdf in starting in section 2.4 Table 2-1. The orderId and amount values can be different if your system cannot pass the ones specified.

We do not recommend sending live card data to the test system.

The certification environment will be upgraded and re‐started typically during the third Tuesday maintenance window of every month. All transactional data, including sessions, batches and payment transactions, will be purged. Merchants and partners can therefore expect from zero to thirty days of transactional data to be present in the certification database.

Provide the following information to your assigned Implementation Consultant: Connection Type(s)(on-line and/or batch) Communication Protocol for online and batch (https post, tcp/ip, ftp, sftp, etc We accept only HTTPS Post for online. Batch you can choose. External IP addresses of the server(s) that will be sending the transactions. Your consultant will setup a test account for you and provide you with the test URL, username, password, and merchantId.

Each IP address connecting to the certification environment receives 3 concurrent connections for real-time processing. A maximum of 5 IPs can be granted access to the the certification environment. A maximum of 10,000 transactions can be sent in a batch file per day.

Your test account does not expire. The account remains open after moving to the live environment. We reserve the right to terminate a user's access to the certification environment if it is determined that usage falls outside of the realm of certification‐level testing, and whose subsequent misuse may adversely affect the overall health of the system and the ability of other merchants and/or partners to properly access and utilize the certification environment.

When creating the PayPage JavaScript make sure to check your line that says: sendToLitle(litleRequest, formFields, submitAfterLitle, onErrorAfterLitle, timeoutOnLitle, 5000); and make sure the timeout limit is set to a number that is appropriate, for example 5000.

No, PayPage extends the functionality of Vault.

The paypageRegistrationId returned is only valid for 24 hours. You must submit the paypageRegistrationId with 24 hours of receiving it to obtain the token.

Each merchant account will have its own unique paypageId to be used in the PayPage request.

Yes, certification testing information for PayPage is located in the Litle_PayPage_Integration_Guide_XML8.7_V2.5.pdf. There are several negative test cases that must be complete to handle all scenarios.

Yes, JavaScript is required for processing the PayPage request.

No, you host the checkout page and control the content. You would just need to add the JavaScript to the credit card number field in the checkout form.

We created a few simple sample pages to see how the code is used and executed: Example checkout page showing all inputs and outputs: https://www.testlitle.com/checkout/checkout2-prelive.jsp Checkout Page without PayPage:https://www.testlitle.com/checkout/before.html Checkout Page with PayPage (will submit primary account number if PayPage encounters an error): https://www.testlitle.com.com/checkout/yesSeeCard.html Checkout Page with PayPage (will never submit primary account number): https://www.testlitle.com/checkout/dontSeeCard.html

The tokens last four digits is the same as the credit cards last four digits and therefore you can show the last four digits of the token for your customers to identify their card.

Through the UI you are able to view the actual card number if you have the permissions to do so. Also, there is an option of a bulk extraction if you would like a large number of tokens un-tokenized.

The expiration date must be sent in with a token. We only tokenize the card number. The token does not include the expiration date or card validation number. When the card expires you can simply send in the new expiration date without replacing the token.

The token does not expire. It can be used until the cardholder changes the account number.

Currently the Virtual Terminal does not allow tokens to be entered for process and does not return a token if a credit card number is entered.

Vault works in conjunction with the auto account updater product. If you are receiving updated information in your response and the account number changes, you will receive a new token in your response.

PayPage is not required when using the vault. The PayPage extends the vault functionality so that credit card numbers never touch a merchants system.

The token is created using a mod 10 plus 1 algorithm. The credit cards use the industry standard mod 10 algorithm. We recommend that all values are validated for the industry standard mod 10 algorithm and the ones that fail will be tokens if all current credit cards pass the mod 10 check.

For credit cards, in an effort to minimize development requirements on the merchant side, we have elected to use a format-preserving tokenization scheme. In simple terms this means that the length of the original card number is reflected in the token, so a submitted 16-digit number results in a 16-digit token. Also, all tokens use only numeric characters, so you do not have to change your systems to accept alpha-numeric characters. The credit card token numbers themselves have two parts. The last four digits match the last four digits of the card number. The remaining digits (length can vary based upon original card number length) are a randomly generated. Unlike credit card numbers, which are Mod 10 compliant, tokens are Mod 10 + 1 compliant.

For an eCheck token, since the account number length can vary widely, we elected to make the tokens a uniform length of 17 digits. Unlike card tokens, the entire eCheck token number is a randomly generated. The system supplies the last three characters of the account number in a separate element. As with credit card tokens, eCheck tokens are Mod 10 + 1 compliant.

You are only charged when a token is registered for the first time.

The file name format is: merchantId.MMddyyyy.sessionId.response

Signature 4: Order ID. You would use Order ID alone to avoid a change in card restarting the sequence.

You must be on Vantiv eCommerce XML version 8.6 or higher to receive recycle advice.

You can be on any version of the Vantiv eCommerce XML to take advantage of the Recycling Engine, but to receive recycle specific responses; you will need to be on version 8.6.

Yes, but you would not be able to get advice in the response using any PTI format.

The file name format is: merchantId.MMddyyyy.sessionId.response

Signature 4: Order ID. You would use Order ID alone to avoid a change in card restarting the sequence.

You must be on Vantiv eCommerce XML version 8.6 or higher to receive recycle advice.

You can be on any version of the Vantiv eCommerce XML to take advantage of the Recycling Engine, but to receive recycle specific responses; you will need to be on version 8.6

Yes, but you would not be able to get advice in the response using any PTI format.

Yes, BML accepts custom billing but they only in the deposit. Taking that into account, we hold the custom billing information that is sent in the auth and then provide it to BML in the following deposit.

No. BML does not accept auth reversals.

BML transactions are certified by BML. There is a direct connection between us and BML's certification systems. The transactions will pass through the our schema and be passed on to BML for their review and certification. We work with BML to assure all requirements are met on both systems.

You must be on Vantiv eCommerce XML version 6.1 or higher to send BML transactions.

They are as follows: New Customer Auth: Where there is no existing BML account present Authenticated: Existing BML customer Not Authenticated: These are Call Center transactions where there is no prior verification available, such as a login or password.

No. You can send BML transactions using the same MID as your Credit Card transactions

"Invalid Data" is an error message that is returned from the BML system. This occurs when the information in the transactions passes our schema, but there is an issue on the BML side. You would need to contact BML for more information.

The subject links your PayPal API account to your account in our system. Without the subject transactions cannot be processed.

Funds are guaranteed for 3 days after an authorization is completed.

To void an order completely you must send the void direct to PayPal via an expressCheckOut call.

Captures can reject if something changes with the PayPal account after the authorization request has taken place. In the credit card world these rejects do not happen at the time of capture. They are rejected via a chargeback. With PayPal they are rejected at the time of capture.

Orders can stay open up to 360 days on a customer's PayPal account unless the amount is fully consumed. To release the funds a orderComplete sent on a capture will close the order even if there are funds remaining.

A PayPal refund must always be linked to the original capture. We do not support a orphan refund for PayPal.

The billing agreement is a way for a recurring charge to be setup with a PayPal account.

The current integration with PayFlow Pro that we offer does not allow for Reference Transactions to be sent.