Overview
The Lightbox approach uses an <iframe> to embed the payment page as an overlay to your online shop.
When the Lightbox Mode is invoked, the merchants online shop is darkened out and the payment page appears as a floating element on top.
Integration
The simple integration uses a <script> tag inside your payment form to render the purple Lightbox button. Upon completion of the Checkout process, Lightbox submits your form to your server, passing along a transaction_response and any elements your form contains.
You can find a demo on this link Demo Lightbox
Transaction response input contains JSON stringified transaction response received as payment processing result. Example:
{
"id":164091,
"acquirer":"integration_acq",
"order_number":"yYiM5TYKTU",
"amount":100,
"currency":"EUR",
"outgoing_amount":100,
"outgoing_currency":"EUR",
"approval_code":"901199",
"responseCode":"0000",
"responseMessage":"approved",
"reference_number":"000002833738",
"systan":"164090",
"eci":"06",
"xid":null,
"acsv":null,
"cc_type":"visa",
"status":"approved ",
"created_at":"2019-05-23T15:31:44+02:00",
"transaction_type":"purchase",
"enrollment":"N",
"authentication":null,
"pan_token":null,
"issuer":"xml-sim"
}
When adding the following code to your page, make sure that the form submits to your own server--side code within the action attribute:
<form action="your-server-side-code" method="POST">
<script src="https://ipgtest.monri.com/dist/lightbox.js" class="lightbox-button"
data-authenticity-token=""
data-amount="100"
data-currency="USD"
data-order-number=""
data-order-info="Lightbox example"
data-digest=""
data-transaction-type="purchase"
data-ch-full-name="Test"
data-ch-zip="Test"
data-ch-phone="Test"
data-ch-email="test@test.com"
data-ch-address="Adresa"
data-ch-city="Grad"
data-ch-country="Croatia"
data-language="en">
</script>
</form>
Digest is calculated using following formula:
digest = SHA512(key + order_number + amount + currency)
With the following example data
- key:
qwert123 - order_number:
abcdef - amount:
54321 - currency:
EUR
the digest formula gives a result as follows:
digest = SHA512("2345kljbcdef54321EUR") # resulting with "f71b8c1560bd7511ba2f0307b3823c06dd39042cd77480543e3d7bf9f3eefa6debed252979ba8edc7a82d9f111d90f8e31c1c7ab5af39796b26e59a0b2d7cf98"
You can check digest on this link Calculate Digest
Data Parameters
Buyer's profile
| name | length | format | lightbox-key | additional info |
|---|---|---|---|---|
ch_full_name |
3-30 | alphanumeric | data-ch-full-name |
buyer's full name |
ch_address |
3-100 | alphanumeric | data-ch-address |
buyer's address |
ch_city |
3-30 | alphanumeric | data-ch-city |
buyer's city |
ch_zip |
3-9 | alphanumeric | data-ch-zip |
buyer's zip |
ch_country |
2-3 | alphanumeric | data-ch-country |
buyer’s country in alpha2, alpha3 letter code or 3 digit ISO numeric code |
ch_phone |
3-30 | alphanumeric | data-ch-phone |
buyer's phone |
ch_email |
3-100 | alphanumeric | data-ch-email |
buyer's email |
Order details
| name | length | format | lightbox-key | additional info |
|---|---|---|---|---|
order_info |
3-100 | alphanumeric | data-order-info |
short description of order being processed |
order_number |
1-40 | alphanumeric | data-order-number |
unique identifier |
amount |
3-11 | integer | data-amount |
amount is in minor units, ie. 10.24 USD is sent as 1024 |
currency |
predefined | alpha | data-currency |
possible values are USD, EUR, or BAM |
Processing data
| name | length | format | lightbox-key | additional info |
|---|---|---|---|---|
| language | predefined | alpha | data-language |
used for errors localization, possible values are en, es, ba or hr |
| transaction_type | predefined | alpha | data-transaction-type |
possible values are authorize, purchase, capture, refund, void |
| authenticity_token | 40 | alphanumeric | data-authenticity-token |
auto generated value for merchant account, can be found under merchant settings |
| digest | 40 | alphanumeric | data-digest |
SHA512 hash generated from concatenation of key, order_number, amount and currency as strings; key can be found under merchant settings |
| number_of_installments | 1-2 | integer | data-number-of-installments |
range 2-12 |
| moto | predefined | boolean | data-moto |
possible value is true or false; missing variable is equivalent to false |
Additional info
| name | length | format | lightbox-key | additional info |
|---|---|---|---|---|
| tokenize_pan_offered | predefined | boolean | data-tokenize-pan-offered |
if true and merchant has secure vault active (tokenization enabled) then save card for future payments will be shown to customer. If customer decided to save the card and transaction is approved we’ll provide pan_token which you can store on your side. |
| supported_payment_methods | predefined | comma separated payment methods | data-supported-payment-methods |
provide this value if customer decides to pay with previously saved card(s) or with new card. If this value is provided and valid (card not expired, token valid etc) then only cvv input will be shown on the payment form. All other information (masked pan, expiry date etc) will be pre filled. Multiple tokens can be sent (separated by comma). In that case, the user will have an option which payment method to use. |
| tokenize_pan | predefined | boolean | data-tokenize-pan |
tokenize pan without prompting the user |
| tokenize_brands | predefined | comma separated list of card brands | data-tokenize-brands |
provide this value if you want to limit card tokenization to card brand(s). Multiple brands can be sent (separated by comma). Refer to tokenize brands section below. |
| custom_attributes | predefined | valid JSON string | data-custom-attributes |
provide this value if you want to customize form behaviour. Refer to the custom attributes section below for more details. |
| external_tokenization | predefined | boolean | data-external-tokenization |
set to true when the payment uses a card token you obtained through your own (external) tokenization rather than Monri's secure vault. Marks the transaction as card-on-file. Possible values are true or false; missing variable is equivalent to false. |
| future_usage | predefined | alpha | data-future-usage |
set on the initial customer-initiated transaction (CIT) to flag the stored card for later merchant-initiated payments. Possible values: unscheduled_recurring (charges with no fixed schedule, e.g. account top-ups) or recurring (charges on a fixed schedule, e.g. subscriptions). When the CIT is approved the callback returns a cit_id (and, with tokenization enabled, a pan_token) that you reuse for MIT charges. See Recurring payments (CIT/MIT) below. |
| merchant_initiated_transaction | predefined | boolean | data-merchant-initiated-transaction |
set to true on a merchant-initiated transaction (MIT) charged against a previously stored card without the cardholder present. Must be combined with data-cit-id and data-supported-payment-methods. Missing variable is equivalent to false. |
| cit_id | — | string | data-cit-id |
identifier of the initial CIT, returned in that transaction's callback (cit_id). Pass the value back unchanged on every MIT so the charge is linked to the original customer consent. |
Recurring payments (CIT/MIT)
Recurring (unscheduled) payments are done in two steps: a customer-initiated transaction (CIT) where the cardholder is present and consents to future charges, followed by one or more merchant-initiated transactions (MIT) charged later against the stored card without the cardholder present.
Step 1 — Initial transaction (CIT). Add data-future-usage (use unscheduled_recurring for charges with no fixed schedule, or recurring for a fixed schedule such as a subscription) to flag the card for future use, and data-tokenize-pan="true" to store it. On approval the callback returns a cit_id and a pan_token — persist both on your side.
<form action="your-server-side-code" method="POST">
<script src="https://ipgtest.monri.com/dist/lightbox.js" class="lightbox-button"
data-authenticity-token=""
data-amount="100"
data-currency="EUR"
data-order-number=""
data-order-info="Initial recurring payment"
data-digest=""
data-transaction-type="purchase"
data-ch-full-name="Test"
data-ch-email="test@test.com"
data-language="en"
data-future-usage="unscheduled_recurring"
data-tokenize-pan="true">
</script>
</form>
Step 2 — Merchant-initiated transaction (MIT). For each later charge, reuse the cit_id and pan_token from Step 1. Set data-merchant-initiated-transaction="true", pass the original data-cit-id, provide the stored token via data-supported-payment-methods, and set data-moto="true".
<form action="your-server-side-code" method="POST">
<script src="https://ipgtest.monri.com/dist/lightbox.js" class="lightbox-button"
data-authenticity-token=""
data-amount="100"
data-currency="EUR"
data-order-number=""
data-order-info="Recurring charge"
data-digest=""
data-transaction-type="purchase"
data-ch-full-name="Test"
data-ch-email="test@test.com"
data-language="en"
data-merchant-initiated-transaction="true"
data-cit-id="<initial CIT id>"
data-supported-payment-methods="<pan token>"
data-moto="true">
</script>
</form>
Note: the initial CIT is marked as an initial transaction and therefore triggers a 3D Secure challenge for the cardholder (a transaction without
data-future-usagestays frictionless). This is expected behaviour required to establish consent for the subsequent MIT charges.
For the underlying transaction model and SCA exemptions, see Recurring payments.
Callback
You can set your callback URL under your merchant profile data if you want us to send a POST request with all the transaction parameters for each approved transaction.
POST request is sent to your endpoint in JSON format.
We expect HTTP 200 OK status response code to terminate the job, otherwise we’ll send the data periodically until we receive 200.
Here is a list of parameters included in callback request:
{
"id":186562,
"acquirer":"integration_acq",
"order_number":"a6b62d07cc89aa0",
"order_info":"order info for a6b62d07cc89aa0",
"amount":100,
"currency":"EUR",
"ch_full_name":"John Doe",
"outgoing_amount":100,
"outgoing_currency":"EUR",
"approval_code":"914783",
"response_code":"0000",
"response_message":"approved",
"reference_number":"000002902038",
"systan":"186561",
"eci":"05",
"xid":"fake authenticated xid +=",
"acsv":"fake authenticated cavv +=",
"cc_type":"visa",
"status":"approved",
"created_at":"2019-09-06T14:24:44.906+02:00",
"transaction_type":"purchase",
"enrollment":"Y",
"authentication":"Y",
"pan_token":null,
"masked_pan":"434179-xxx-xxx-0044",
"issuer":"zaba-hr",
"number_of_installments":null,
"custom_params":"{a:b, c:d}"
}
Migrating from data-whitelisted-pan-tokens
Simply replace key data-whitelisted-pan-tokens with a key data-supported-payment-methods and you are good to go!