Pay By Link

Pay By Link (IPR) is a mechanism that allows two people to participate in the payment process: one (the requester) generates a payment link, which is sent via SMS, and the other (the recipient) uses that link to complete the payment.

Payment link

There are many reasons to use payment links, with or without a full-fledged e-commerce presence. Two major use cases are:

  1. Delegated payment: person A fills the shopping cart and initiates checkout, and then generates a payment link for person B to use. For example, a personal assistant who doesn't have their employer's credit card details may generate payment links for the employer to perform the actual payment. In this scenario, person A is actively using the merchant website, initiates checkout, and, once on the payment page, chooses to send a payment link to person B.

  2. Conversational sales through call centers: instead of making the customer share their credit card details over the phone, a sales representative can send a payment link that the customer can use to make a payment in a secure manner. In this scenario, the sales representative doesn't even need to access the merchant website in order to generate a payment link.

The difference between these two scenarios lies in how much the requester interacts with the payment page.

Prerequisites and terminal configuration

Pay By Link is not enabled in terminals by default. Please contact your Hyp representative to have it enabled.

Payment experience

If Pay By Link is enabled in your terminal, the payment page contains the Payment Link button in addition to the regular credit card payment section:

Payment Link button

When the requester clicks the Payment Link button, the payment page displays a field to enter the recipient's phone number, as well as a button to send an SMS with the payment link to the phone number:

Phone field

The field only accepts Israeli phone numbers in the short format, e.g., 0501234567.

Once the phone number is entered and the requester clicks Payment link, the payment page displays an overlay indicating that the payment request is pending:

Payment link overlay

Meanwhile, the recipient receives an SMS in Hebrew that contains the payment link:

התקבלה בקשת תשלום מ: HYP Test לביצוע התשלום, יש ללחוץ על הקישור המאובטח המצורף. מטעמי בטיחות, הקישור הינו חד-פעמי ויישאר פעיל למשך 10 דקות בלבד. https://ppsuat.creditguard.co.il?txId=427d6754-4b75-4f7a-982c-e10c13c5b775

The payment link is single-use and expires after 10 minutes.

When the recipient clicks the link, they see the Hyp payment page with all payment methods available in the terminal:

Payment page for the recipient

Once the recipient completes the payment, both the requester’s and the recipient’s payment pages are redirected to success pages.

Payment page integration

As soon as Pay By Link is enabled in your terminal, the Payment Link button displays on your payment pages by default, without any additional setup, unless you have chosen to hide this payment method.

Delegated payment

When Pay By Link is enabled in your terminal, the delegated payment flow described above works out of the box: the requester opens the payment page, clicks the Payment Link button, fills out a phone number, and clicks Payment Link again to send an SMS to the recipient. The recipient clicks the link from the SMS, opens the payment page, and completes the payment.

Conversational sales

For conversational sales and similar scenarios, you can take several steps to minimize the requester's involvement with the payment page. In the extreme case, you can even open the page in the background, so the requester only needs to click a button integrated with their workspace, and that's all it takes for the recipient to get a payment link via SMS.

First of all, you can pre-populate the recipient's phone number in the payment page's Tel To Receive Payment Link field. In the doDeal part of your request, add the cardHolderPhoneNo element:

As a result, when the requester opens the payment page and clicks the Payment Link button, the phone number field in the resulting view will be pre-populated with the number specified in the request.

You can also make the payment link view open by default when the payment page loads, skipping the initial view with credit card fields and payment method selection. In this case, the requester needs to perform one click to open the payment page and, if the phone number is pre-populated, one more click to send the payment link.

To do this, you need to add a JSON configuration object to your request similar to what you do when you want to change the default payment page appearance. In the configuration object, under uiCustomData, you need to set defaultPaymentMethod to ipr, and in the paymentMethods array for the ipr method, set the autoSubmit property to false:

Finally, you can trigger a payment link to be sent out immediately when the requester opens the payment page. This requires the phone number to be pre-populated as shown above. As a result, the requester only needs one click to dispatch a payment link to the recipient. To do this, set the autoSubmit property for the ipr payment method to true:

If you're integrating Hyp CreditGuard with a CRM or a similar system that the requester uses, you can go a step further and avoid showing the payment page to the requester entirely. Normally, you send a POST request to Hyp on the backend, then provide the payment page URL from the response to your frontend to handle, which results in opening the payment page in the customer's browser. Instead, you can open the payment page URL on the backend in a headless browser, using a framework like Playwright. This will trigger sending an SMS with a payment link to the recipient without the requester ever opening the payment page.

Customizing the payment page for the recipient

When the recipient clicks the payment link, they open a full payment page with the default look and feel and all payment methods enabled in your terminal.

To customize the payment page that the recipient sees, you can use all the JSON configuration options described in Changing the Default Payment Page Appearance, but instead of wrapping them in ppsJSONConfig, you wrap them in the paymentDemandJSONConfig element.

Last updated

Was this helpful?