Basic Integration Flow: Hello World With a Full Working Charge
This page describes the easiest way of integrating your merchant website with Hyp CreditGuard, covering both the user and developer perspectives. It consists of the following steps:
The user clicks a checkout link on the merchant website.
The merchant website makes an API call to Hyp CreditGuard requesting a payment page to be generated.
Once it receives a payment page URL, the merchant website redirects the user to the payment page. The merchant website also passes URLs to open in case of successful payment or payment error.
The user enters their credit card details and clicks the Pay button.
Hyp CreditGuard performs the transaction, determines its status, and redirects the user to one of the URLs provided by the merchant website depending on the status of the transaction.
(Optional) The merchant website checks the validity of the transaction.
After reading this page, you will understand how to set up a simple payment flow to charge a credit card using the Hyp CreditGuard API. This flow is also described in Integrating Hyp’s Payment Page and Accepting Payment in a more general way, without focusing on implementation details.
Code samples on this page are written in JavaScript, and assume the use of Express.js on the backend and vanilla JavaScript/HTML on the frontend. If you're using a different tech stack, you may need to change the frontend and backend code, but the principles of interacting with the Hyp CreditGuard API will remain the same.
Prerequisites
This page assumes that you have completed all the prerequisites and requirements for making Hyp CreditGuard API calls, such as obtaining a username, password, merchant ID, and terminal number.
Step 1. Request a payment page from your checkout page
The most common way of requesting a payment page is from a checkout page on your merchant website. When visiting this page, the user has already selected products that they want to buy, added them to their shopping cart, specified shipping details, and entered any coupon codes that may have influenced the pricing of the selected products. Viewing the checkout page is the last chance for the user to review products to buy before proceeding to pay for them.

On this page, the user is now ready to proceed to payment when they click the Checkout button.
As a developer integrating with Hyp CreditGuard, you want to add a handler to the Checkout button that requests a basic credit card payment page from Hyp CreditGuard.
Let's assume that your checkout page has the following Checkout button:
When the user clicks the button, your handler on the frontend may be similar to this:
This handler makes a call to your backend's /checkout endpoint, and that's where the first call to the Hyp CreditGuard API happens:
Here's a summary of what happens in this endpoint:
You send a
POSTrequest to the Hyp CreditGuard API endpointhttps://your-hyp-environment-url/xpo/Relay, passing your merchant credentials and transaction details in XML format, wrapped in a parameter calledint_in. Make sure to use the base URL provided to you by Hyp instead ofyour-hyp-environment-url.You parse the response looking for the payment page URL that Hyp CreditGuard has generated for you. This URL is provided in the
mpiHostedPageUrlelement.If the payment page URL is found, you return it for your frontend to use; otherwise, you return an error.
Most of the XML elements that you include in your request's int_in parameter in this basic scenario should be used exactly as in the code sample above. Here's a list of variable elements:
terminalNumber: a unique number assigned to you as a merchant during registration.
language: defines the UI language of the requested payment page and the language of text values in the XML response. UseHEBfor Hebrew orENGfor English. Other language codes are not supported and will fall back to English. Note that there's an alternative method of setting the UI language of the payment page - see Changing the UI Language for details.
total: the total payment due in currency subunits, such as cents or agorot. For example, if the total in the user's payment cart is $47.30, the number that you pass in thetotalelement should be 4730.
currency: the currency code according to ISO-4217. For example, ILS for Israeli new shekels, USD for US dollar, etc.
mid: merchant ID assigned to you as a merchant during registration.
uniqueid: a string ID of up to 64 characters that you generate for each transaction and that should be unique for at least the last 24 hours. In the code sample above, it is generated with the uuid package that implements the RFC 9562 standard.
successUrl: the URL on the merchant website that Hyp CreditGuard should redirect to upon successful payment.
errorUrl: the URL on the merchant website that Hyp CreditGuard should redirect to in case of a payment error.
Step 2. Redirect the user to the payment page
A typical successful response to the request sent in step 1 looks like this:
As long as the value of resultis 000, signifying a green light to perform the transaction, you're only interested in the payment page URL, which is found in the mpiHostedPageUrl element:
You need to read this value and return it to your frontend. When the frontend receives the URL, it can redirect the user to the payment page:
Step 3. Wait for the user to enter payment details on the payment page
When redirected, the user finds themself on the landing page hosted by Hyp CreditGuard. If you've set language to ENG in your request, the payment page looks like this:

The user can now enter their payment details securely, without exposing them to your website, thereby freeing you as a merchant from many PCI DSS requirements.
After entering payment card details, the user can click the Pay button. Hyp CreditGuard then processes the payment card details. Upon completion, Hyp CreditGuard redirects the user to the success or error page on your merchant website that you've specified in your original payment page request.
If the user was redirected to the success page, you may want to perform an additional step: validate the transaction.
Step 4. Validate the transaction
Once the user has been redirected to the success page, the transaction is technically complete. However, some merchants may want to validate the transaction for regulatory or security policy reasons.
You can validate the transaction in one of two ways:
Send an additional request to Hyp CreditGuard providing the transaction ID and receive a response confirming the outcome of that transaction.
Compare the MAC (message authentication code) received from Hyp CreditGuard with the MAC that you calculate yourself.
For details on both of these methods, see Transaction Validation.
The MAC validation method is faster since it allows you to skip making another API call. Let's see how to use it.
When redirecting to your success or error page, Hyp CreditGuard passes a query string with several parameters. Below is a sample success page URL with its query parameters:
One of the parameters, responseMac, is the MAC calculated by Hyp CreditGuard. You must use several of the other parameters and your merchant password to calculate MAC on your end, and then compare it to responseMac. If they're identical, it means that the transaction is valid.
First, concatenate the following values in this exact order:
Your merchant password.
txId(transaction ID) from the query string.errorCode(if received;000otherwise).cardToken(if received; an empty string otherwise).cardExp(if received; an empty string otherwise).personalId(if received; an empty string otherwise).uniqueId(your unique merchant ID).
If any parameters are empty, use an empty string instead. One notable exception is errorCode: if it's empty, use the value 000 instead.
Hash the resulting string using SHA-256, transform it to base64, and compare the resulting value with responseMac.
Let's see how this can be implemented in the sample Express.js application.
On the frontend, your success page may look like this:
It makes a call to the validate-mac endpoint on your backend, passing the query string. When the response arrives, it displays the transaction verification status to the user accordingly.
The validate-mac endpoint on the backend is as follows:
Here's what happens in this code snippet:
All parameters required for MAC calculation and comparison are extracted from the query string passed from the frontend.
The merchant password and the parameters used in MAC calculation are saved in a specific order to an array, which is then converted to a string.
The
cryptoNode module hashes the resulting "base" string using SHA-256 and outputs it as a hexadecimal string. The result is stored in thecalculatedMacvariable.The endpoint returns
{valid: true}if the calculated MAC matches the MAC received from Hyp CreditGuard, and{valid: false}otherwise.
Common pitfalls and troubleshooting
Invalid API credentials
Ensure that your API credentials (username, password, terminal number, merchant ID) are correct and match the environment (test or production). Ensure you store them securely using a secret manager or environment variables, and only use them on the backend of your application.
Wrong total amount
Note that Hyp CreditGuard expects the total amount as a string representing the number of cents, agorot, or equivalent currency subunits. If you store prices differently, such as in fixed-point decimals, make sure to perform the necessary conversions before passing the total due to Hyp CreditGuard.
MAC calculation pitfalls
Make sure to provide default values for the parameters used in calculating MAC on your backend. If a parameter is not provided in the query string received from Hyp CreditGuard, explicitly replace it with an empty string to avoid concatenating unexpected values such as null and undefined. For the errorCode parameter, remember that instead of an empty string, it should be replaced with 000 if empty.
Last updated
Was this helpful?