Existing customers: Get your sandbox and production credentials for Heartland/Portico integration.
Accepting credit and debit cards is fundamental for eCommerce and other businesses interested in expanding their customer base, increasing their sales potential. You can learn how to set that up here.
When you get into the Sandbox, you’ll find a Tokenization Demo for JSFiddle examples. For a more in-depth guide to card payments see our full SDK documentation. You can also view our open source library on GitHub.
All card-not-present transactions must include cardholder’s street address, ZIP Code, and CVV to pass certification. This includes online payments and ecommerce transactions. These values must also be presented in production to assist our Disputes Team in case of a chargeback and to help protect the transaction against fraud.
<form id="payment-form" action="/Payment/Charge" method="get">
<!-- Other input fields to capture relevant data -->
<label for="billing_zip">Billing Zip Code</label>
<input id="billing_zip" name="billing_zip" value="47150" type="tel" />
<!-- Target for the credit card form -->
<div id="credit-card"></div>
</form>Make sure to replace the publicApiKey with your production key when moving to the live environment.
Heartland tokenization uses the public API key to identify you and your target environment (for example, Certification, Production, etc.). So, when moving your application from the testing/certification environment to production, you need to update this in your code.
When the consumer submits the form, the payment_token field is updated to contain a single-use payment token. This token can be used to make a payment and request a multi-use token.
If you’re interested in implementing a recurring payment system with our multi-use tokens, there are additional options that must be configured during the onboarding process. Contact your Heartland representative to learn what you need to know.
Our iframe-based input fields include built-in validation features to improve data accuracy and user experience during checkout.
.valid or .invalid based on the input state, allowing you to distinctly style valid and invalid fields..card-type-{brand} class (e.g., .card-type-visa), enabling you to display the appropriate card brand logo as a visual cue.These classes can provide real-time feedback, highlight input issues, and guide users through form completion.
Once the consumer has entered their card information and submitted the payment form, the next step is to charge the token. In this step, you’ll configure the server-side SDK to collect the necessary data.
With the CreditCardData and Address objects initialized, you can use them to charge the consumer’s card. The Heartland server-side SDKs expose the payment method directly on payment objects such as CreditCardData.
Declines and general errors can occur during processing. The server-side SDKs throw exceptions when the issuing bank declines a transaction or the input data fails validation. To handle these cases, wrap your charge request in a try/catch function.
Refer to the Error Handling section for details on exception types and how to identify the root cause of errors.
Ready to dig deeper? Check out the additional resources below to learn more about our ecommerce card payments solution.
Get an in-depth guide to card payments
View our open source library
Find everything you need to know to work with our payment gateway.
We’re here to help. Contact us if you have any questions or need assistance.