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.
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.
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.
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.
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
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).
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 firstname.lastname@example.org. 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 email@example.com for more information.
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.
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.
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.
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.
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.
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.
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.
sendToLitle(litleRequest, formFields, submitAfterLitle, onErrorAfterLitle, timeoutOnLitle, 5000);
and make sure the timeout limit is set to a number that is appropriate, for example 5000.
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.
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 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.
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.
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.
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.
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.
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.
"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.
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.