Loading...
Existing customers: Get your sandbox and production credentials for Heartland/Portico integration.
While credit and debit card acceptance cover most use cases, offering check-based payments (such as eCheck or ACH) can be preferable in certain scenarios, particularly for business-to-business transactions. Learn how to set that up here.
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.
As with other payment types, your integration must collect sufficient customer data based on your merchant account configuration. The fields shown in the code block below represent a typical baseline for ACH/eCheck transactions using our ACH solution. Note that the required fields may vary for Sage/GETI so be sure to consult the specifications for the integration you’re building.
<form id="payment_form" method="post" action="/process">
<!-- account fields -->
<label for="account_number">Account Number</label>
<input id="account_number" name="account_number" type="tel">
<label for="routing_number">Routing Number</label>
<input id="routing_number" name="routing_number" type="tel">
<label for="account_type">Account Type</label>
<select id="account_type" name="account_type">
<option value="CHECKING">Checking</option>
<option value="SAVINGS">Saving</option>
</select>
<label for="check_type">Check Type</label>
<select id="check_type" name="check_type">
<option value="PERSONAL">Personal</option>
<option value="BUSINESS">Business</option>
</select>
<!-- address fields -->
<label for="check_holder_name">check_holder_name</label>
<input id="check_holder_name" name="check_holder_name" type="text">
<label for="billing_street_address_1">billing_street_address_1</label>
<input id="billing_street_address_1" name="billing_street_address_1" type="text">
<label for="billing_city">billing_city</label>
<input id="billing_city" name="billing_city" type="text">
<label for="billing_state">billing_state</label>
<input id="billing_state" name="billing_state" type="text">
<label for="billing_zip">billing_zip</label>
<input id="billing_zip" name="billing_zip" type="text">
</form>Once the consumer has entered their ACH/eCheck information and submitted the payment form, the next step is to charge the account. In this step, you’ll learn how to configure the server-side SDK and prepare the required data fields for the transaction request.
During certification and validation, you will receive a developerId and versionNumber. These values uniquely identify your integration and remain consistent even if your integration supports multiple merchant accounts or locations.
Before running your assigned tests, replace any placeholder or zeroed values for developerId and versionNumber in your code with the provided credentials.
When transitioning from the sandbox or certification environment to production, update your integration with the production API key associated with your live merchant account. Also, ensure the service URL is set to the production endpoint:
In this step, you’ll create the eCheck and Address objects, which are needed to initiate the charge. Our server-side SDKs expose the charge operation directly on payment objects including eCheck.In this step, you’ll create the eCheck and Address objects, which are needed to initiate the charge. Our server-side SDKs expose the charge operation directly on payment objects including eCheck.
When you initiate a charge using the server-side SDK, the response includes a Transaction object. You can store any fields from this object in your application’s database or use them to display relevant information to the customer.
Declines and general errors can occur during ACH and eCheck processing, so you’ll want to build the ability to handle that smoothly into your application.
The server-side SDKs throw exceptions when the issuing bank declines a transaction or if the input data fails validation. To handle these cases, wrap your charge request in a try/catch function. In the Error Handling section, you can find additional guidance on using specialized types of try/catch functions for identifying the root cause of exceptions.