LightBox implementation



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.


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.

Transaction response input contains JSON stringified transaction response received as payment processing result. Example:

  "status":"approved ",

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="" class="lightbox-button"
    data-order-info="Lightbox example"
    data-ch-email="[email protected]"


Digest is calculated using following formula:

digest = SHA512(key + order_number + amount + currency)

With the following example data

the digest formula gives a result as follows:

digest = SHA512("2345kljbcdef54321EUR") # resulting with "f71b8c1560bd7511ba2f0307b3823c06dd39042cd77480543e3d7bf9f3eefa6debed252979ba8edc7a82d9f111d90f8e31c1c7ab5af39796b26e59a0b2d7cf98"

Data Parameters

Buyer’s profile

name length format additional info
ch_full_name 3-30 alphanumeric buyer’s full name
ch_address 3-100 alphanumeric buyer’s address
ch_city 3-30 alphanumeric buyer’s city
ch_zip 3-9 alphanumeric buyer’s zip
ch_country 2-3 alphanumeric buyer’s country in alpha2, alpha3 letter code or 3 digit ISO numeric code
ch_phone 3-30 alphanumeric buyer’s phone
ch_email 3-100 alphanumeric buyer’s email

Order details

name length format additional info
order_info 3-100 alphanumeric short description of order being processed
order_number 1-40 alphanumeric unique identifier
amount 3-11 integer amount is in minor units, ie. 10.24 USD is sent as 1024
currency predefined alpha possible values are USD, EUR, BAM or HRK

Processing data

name length format additional info
language predefined alpha used for errors localization, possible values are en, es, ba or hr
transaction_type predefined alpha possible values are authorize, purchase, capture, refund, void
authenticity_token 40 alphanumeric auto generated value for merchant account, can be found under merchant settings
digest 40 alphanumeric 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 range 2-12
moto predefined boolean possible value is true or false; missing variable is equivalent to false

Transaction management through API

WebPay API for capture/refund/void is a REST web service and you will need a HTTP client library (like cURL - All API calls are XML documents POST-ed over HTTPS to our test server at

IMPORTANT Parametrize URL, in production mode the subdomain will be different.

An example of such call using cURL from command line may look like this:
curl -H “Content-Type: application/xml” -H “Accept: application/xml” -k -i -d request_xml

where request_xml is a XML document that contains data necessary for transaction processing and is an URL that responds to certain API call.

IMPORTANT Accept and Content-Type headers must be set to application/xml for all message types.


After an authorization is successfully made, a capture call must be done to settle that authorization.
Capture XML document is POST-ed to where
:order_number has a value from original authorization.

Document example for capture message may look like this:

<?xml version="1.0" encoding="UTF-8"?>

Digest is calculated in the following way:
digest = SHA1(key + order_number + amount + currency)

NOTICE Node names are dasherized version of corresponding variable names, ie. underscores are replaced with dashes.

If all values pass validations at our side, transaction is send to the bank and response is returned. That response may look like this:

	:date=>"Tue, 25 Oct 2011 01:18:37 GMT",
	:content_type=>"application/xml; charset=utf-8",
	:x_runtime=>"1.475305", :transfer_encoding=>"chunked"
<?xml version="1.0" encoding="UTF-8"?>
    <id type="integer">845</id>
    <acquirer>rogach bank</acquirer>
    <amount type="integer">54321</amount>
    <response-message>authorization OK</response-message>
    <created-at type="datetime">2011-10-25T03:18:38+02:00</created-at>

New transaction is generated - 201 Created HTTP status code, and it’s location is set in appropriate HTTP header. A client then must parse a body from HTTP response and extract all values from that XML document. Transaction is approved only and if only status is set to approved. All other fields are standard data carried over payment networks. If issuer declines a transaction, status flag is set to decline. In a case of an error, the flag will be set to invalid.

IMPORTANT Do not rely on any output variable except status to determine success of capture.

NOTICE We highly recommend to our merchants to keep a whole response string and to save all parsed values for easier troubleshooting during the integration phase and production later on. The quality of our support depends on availability of these information.

In case of invalid request, service will also return a response with
406 Not Acceptable HTTP status code and XML document in its body. Each offended variable will be printed out along with brief explanation what went wrong. That response may look like this:

<?xml version="1.0" encoding="UTF-8"?>
    <error>Digest is invalid</error>


Purchase and capture messages can be refunded within 180 days. Request XML for this transaction_type is identical to capture example, but now the document is POST-ed to, where
:order_number has a value from original purchase or capture.
Response has identical structure as capture response and all response fields should be treated in the same way.


Void messages are POST-ed to, where
:order_number has a value from original message (authorization, capture, purchase or refund). They have identical structure as capture or refund messages.
Response has identical structure as capture response and all response fields should be treated in the same way.

##3D Secure
WebPay handles 3D secure processing for you, this kind of integration doesn’t require any additional programming.

Email notifications

Service can notify merchant and buyer upon successful purchase. Merchant can use this message to track pending transactions and buyer can keep them as reference.
Both can be customized under your merchant account.


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 re-ceive 200.
Here is a list of parameters included in callback request:

  "order_number":"e6979204d6a 8632",
  "outgoing_c urren-cy":"USD",
  "respo nse_message":"approved",
  "sytan":"14 6191",
  "status":"ap proved",
  "transaction_type":"pu rchase",
  "mask ed_pan":"411111¬xxx¬xxx¬1111",
  "custom_params":"{a:b, c:d}"

Additional info

data-tokenize-pan-offered = "true" – 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.

data-whitelisted-pan-token = "" - provide this value if customer decides to pay with previously saved card(s). 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 in-formation (masked pan, expiry date etc) will be prefilled. Mul-tiple tokens can be sent (separated by comma). In that case, the user will have an option which card to use.

data-tokenize-pan="true" - tokenize pan without prompting the user

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.

data-custom-attributes` provide this value if you want to customize form behaviour. Refer to custom attributes section below for more details.

Tokenize 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).

This value is used in conjunction with data-tokenize_pan_offered = "true" .

Supported brands: