How to integrate with Telr

#telr #payment #gateway

Request method and format

All transaction requests must be sent to the Hosted Payment Page gateway URL:

https://secure.telr.com/gateway/order.json

The HTTP POST data fields that contain the basic purchase information are as follows:

Field	Description
ivp_method	The request method being used
ivp_store	Your store ID
ivp_authkey	Your authentication key
ivp_amount	Transaction amount
ivp_currency	Currency the transaction is in
ivp_test	Test mode indicator `0` or `1`
ivp_cart	Cart ID / Order ID `unique ID`
ivp_desc	Purchase description
return_auth	URL for authorised transactions
return_decl	URL for declined transactions
return_can	URL for cancelled transactions

Test mode requests can be sent from any IP address, but live mode requests will only be accepted from a pre-approved list of IPs (the IP address details for your production systems will be required prior to any live processing)

The response is formatted as JSON.

Order created

{
  "method":"create",
  "order":{
    "ref":"OrderRef",
    "url":"https://secure.telr.com/gateway/process.html?o=OrderRef"
  }
}

after that we need to open the url order.url from the response to complete the payment operation.

Error

{
  "method":"create",
  "error":{
    "message":"E56:Duplicate transaction",
    "note":"Cart ID must be unique"
  }
}

Optional additional request fields

In addition to the basic transaction request fields there are other fields that can be included within the request that can alter the way the request is processed.

Supplying customer details

If your systems have the customer details available then you should include the customer’s name, address and email information as part of the request.

Field	Description
bill_title	The customer’s title.
bill_fname	Forenames
bill_sname	Surname
bill_addr1	Address line 1
bill_addr2	Address line 2
bill_addr3	Address line 3
bill_city	City
bill_region	Region/State
bill_country	Country
bill_zip	Post/Area/Zip code
bill_email	Email address
ivp_lang	Payment Page interface language
ivp_update_url	Transaction advice service type URL

If any part of the customer details are not supplied, or if they are not valid, then the payment pages will prompt for the correct details.

For example, if you have supplied name and email but not their address, then the payment pages will only ask for the address.

Stored Cards (Returning Customers)

The Hosted Payment Pages can provide customers with the option to store their card details for future use, making it simpler for a customer to complete the checkout process the next time they purchase from your store.

There are some key requirements in order to enable stored cards: The acquiring bank that your merchant account is with must support continuous authority transactions.
Your store must be operating from a HTTPS server. You must have a method of identifying each individual customer, with a unique ID for each.
Customers must be required to provide some form of authentication (such as username and password) within your store. This must be done using a HTTPS server.
Customer authentication details (such as their password) must be securely managed within your system, and must only be stored using strong hashing algorithms with a random salt for each hash.

To enable the stored card system, you first need to select the ‘Stored cards’ option within the payment page configuration in the Merchant Admin System.

Field	Description	Notes
bill_custref	Unique customer ID	Optional. If set, the customer may be given the option to store their card for future use if the transaction is authorised, and will be presented with a list of stored cards (if any) at the start of a transaction.

The bill_custref field must not be set if the checkout is not for a registered customer – such as if the customer is using a guest checkout option, or if they have not yet registered within your store.

Recruitment Payment

The Repeat Billing system gives merchants who use the Hosted Payment Pages the ability to setup and manage automatic recurring payments, such as those used in a subscription service.

There elements that form a Payment Agreement are as follows:

Initial payment amount
Payment period (Monthly or Weekly)
Payment interval (Interval between payment periods, e.g. every 2 weeks)
Regular payment amount
Start date (when to start the regular payments)
Term (how many payments to take)
Final payment amount (Any additional final payment to take after the last regular payment)

Sending the payment agreement details

Field	Description	Notes
repeat_amount	Regular payment amount	The amount to be taken at each payment interval.
repeat_period	Agreement billing period	This can be set to either ‘M’ (Months) or ‘W’ (Weeks)
repeat_interval	Number of Weeks/Months between each payment	Set to 1 to bill every month/week (as per billing period).
repeat_start	Agreement start date	Formatted as DDMMYYYY. The start date cannot be the same date that the agreement is made on, and cannot be a date that has already past.
repeat_term	Agreement term	Indicates the number of regular payments to take. Set this to zero to indicate an unlimited term.
repeat_final	Final payment amount	0 if there is no final payment amount. Final payment can only be set if there is a fixed term to the agreement.

All payment amounts are taken in the same currency as used for the main transaction request (as sent in the field). The amounts must be sent in major units (for example, 9 dollars 50 cents must be sent as 9.50 not 950).

Immediate Payment Amount

This specifies an amount to be taken at the same time that the agreement is setup. The immediate payment amount is sent as the ivp_amount field in the main transaction request.

Regular Payment Amount

This is the amount that will be taken from the card holder for each payment.

Agreement period and interval

The period must be set to either ‘M’ or ’W’, which relates to Months or Weeks. The interval must be an integer value between 1 and 12.

Examples
repeat_period=M , repeat_interval=1 , repeat_term=12	12 payments taken one month apart – agreement duration is 1 year.
repeat_period=M , repeat_interval=3 , repeat_term=0	Payments taken every quarter, no fixed term. Payments will continue until such time as the agreement is cancelled.

Start date

This indicates when the first regular payment should be taken. It is an 8 digit value, formatted as DDMMYYYY where DD = 2 digit day, MM = 2 digit month and YYYY = 4 digit year.

repeat_start=20042020 is meaning 20 th of April 2020

Final payment amount

This specifies an amount to be taken at the end of the agreement. This is only applicable for fixed term agreements (where repeat_term is non-zero). This final amount is in addition to any amount that would be taken as part of the regular payment processing. It will be taken at one payment interval following the last regular payment.