DEV Community

Mohammed Aktaa
Mohammed Aktaa

Posted on

How to integrate with Telr

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.

For fixed term payments:
  • Initial payment amount (ivp_amount)
  • repeat_term * repeat_amount
  • repeat_final
For unlimited term payments:
  • Initial payment amount (ivp_amount)
  • Continual payments of repeat_amount until the agreement is cancelled.

You can test it here.

https://mohammadaktaa.me/telr

Top comments (2)

Collapse
 
zargamhussain1 profile image
Zargam Husayn

Brothr when i'm doing payment show error message "Connection from unauthorised IP " how to fix this?

Collapse
 
hafizadil321 profile image
hafizadil321

Brothr when i'm doing payment show error message "Connection from unauthorised IP " how to fix this? please tell me