Some examples

Plugin testing (only for enterprise)

If you are using enterprise plan (Enterprise license on licenses page) then you are given one more option of testing the plugin.
Instead of using built-in system you can work on plugin in your builder at once.
All plugins are stored in builder folder "plugins" and are distributed by folders.
To add your plugin in builder you need to take the following steps:

register your plugin in builder by adding it to file "plugins/plugins-ext.json" (create it if it does not exist; this file should share the same structure with file "plugins/plugins.json")

After adding plugin you can test it in admin builder mode ("Create custom templates" link in your Enterprise license).

To make plugin available for all your customers set parameter {"admin": false} in file "main.json".

Using PHP code in plugin (only for enterprise)

Sometimes it is not enough to use HTML/Javascript code for creating plugin. Often 3rd party plugins provide REST API for integration or manipulation of the system, for example:

shops require saving orders

plugins may use PHP libraries

plugins may require encrypting form fields before submitting what requires server-side script like PHP

To add PHP code into your plugin take the following steps:

create file "main.php" in your plugin folder and write your PHP code

open file "main.html" and add marker {{{requireService}}}. The marker will be replaced with PHP code in published website

open file "plugins/plugins_whitelist.json" and add your plugin name to php list

Note.PHP code is not loaded in site builder but only in published website.

Adding multiple PHP files to plugin

Let's say you develop plugin which integrates some 3rd party system to your site. This system provides PHP SDK which you want to use.
The PHP SDK can be a folder which contains one or multiple .php files, other folders containing other files, etc.
To add all this PHP library to your plugin take the following steps:

create folder "site" in your plugin folder

add all needed 3rd party files/folders into folder "site"

After that you will have access to folder "site" within your PHP file "main.php".
Let's presume you have file in your plugin "myplugin/site/SomeLibrary.php". Then you can load this file with line require_once("SomeLibrary.php"); in your PHP file.

E-commerce plugin (only for enterprise)

In this section e-commerce plugin is considered as a payment gateway which can be added to "Store Cart" widget in builder.
Let's say you need to have payment gateway in your Store which does not currently exist in site builder. Then creation of e-commerce plugin is a right choice.

Simple payment plugin

The creation of e-commerce plugin can be started from creation of a simple payment plugin. Let's name simple payment plugin a button for which website owner can set some predefined product(s), amount, price, etc. (similar to Buy Now button of Paypal system). To deal with it you need to use documentation (API) of payment gateway system which you want to integrate — you will need to know what parameters and what endpoint you need to submit the form to.

Let's write the code for a simple payment plugin for a dummy payment gateway:

We added "main.php" file to make payment gateway look more realistic — so that it requires submitting encrypted password with the form rather than plain password value.Usually payment systems require to encrypt set of some form field values and add it to that form as an extra field.

On website the {{{requireService}}} string will be replaced with an output that PHP code generates.

The plugin does not do much — it creates form which submits order information to payment system by clicking button "Pay". The payment system handles sent data and offers payment methods to a client.

The plugin properties dialog should look like this in builder interface:

Payment gateway plugin for Store Cart widget

To integrate your plugin to store some changes must be made to a simple payment plugin:

modifying file "main.js"

modifying files "main.html"

adding PHP file with payment gateway class description

Modifying file "main.js"

The site builder should know that your plugin is a payment gateway and it has to be included to Store Cart widget as an option.
To let builder know about it we add the following code at the very beginning of "main.js" file:

name — Name of payment gateway system inside Store Cart widget. This property is only informative and does not affect any plugin logic.

id — This property tells builder what plugin payment gateway will be associated with. The value for this property must be the same as your plugin name.

priceFieldId — Just specify field ID which stands for price in your property "propertyDialog" in "main.js". From the beginning the price is not known in Store and therefore it is replaced with a special placeholder {{price}} in HTML form. When you submit the form this placeholder will be replaced with a real order price and sent to payment system.

keyFieldId — Specify merchant field ID here (or any other parameter which is related to payment system merchant identifier).

keyField2Id — Here we presume that our Dummy payment gateway specifies password which must be also used in the form (for example in signature calculation). So we add it as a second parameter.Note: You can use any number of parameters of such format: keyField3Id, keyField4Id, etc.

keyFieldDef — This field accepts object which describes layout of properties specified above (keyFieldId, keyField2Id) in Store Cart properties dialog. The structure of this object is the same as of "propertyDialog". Developing your payment gateway you can see examples of this property used in other predefined payment gateways (e.g. in "plugins/assist/main.js").

nameFieldId — Just specify field ID which stands for product name/description in your property "propertyDialog" in "main.js".

globalVars — Specify array containing field IDs which you will need to have in PHP code. In example above we specified fields "merchant" and "password". We presume that after successful payment the payment system will send IPN (Instant payment notification) to website which must be handled properly. The information which payment system sends in this step can be encrypted and to decrypt it you might use your merchant ID or password values.Note: Of course this depends on payment system. You must read documentation which payment system provides and be able to handle payment result properly. If payment system for which you implement plugin does not use IPN or it does not require calculating signature then you can omit property "globalVars".

After adding this part of code you should see something like this in Store Cart widget properties dialog:

Modifying file "main.html"

When you integrate your plugin in Store widget then a special variable {{content.store}} is available inside "main.html" file.
Let's see how the file should look like now:

Made attribute target="_blank" not used in form when the form is used in Store widget.

Added attribute data-gateway-id (this is required for Store widget).

Added form parameter {transactionId}. This is a placeholder which will be replaced with a real transaction ID generated by Store widget when submitting the form.

Added form parameters {callbackUrl}, {returnUrl}, {cancelUrl} and {verifyUrl}. These are placeholders which will be replaced by real URLs generated by Store widget when page is loaded. Let's consider these parameters in more detail:

{callbackUrl} — Add this placeholder if your payment system supports IPN. The placeholder will be replaced with URL which must be used by payment system as IPN URL.Note: Some payment systems do not support passing URL as a form parameter. Intead they let you pre-configure this URL in merchant account. In such case just do not add this parameter to the form and see how this issue is solved in predefined payment gateway plugin "Robokassa" (file "plugins/robokassa/main.js").

{returnUrl} — Add this placeholder if your payment system supports return URL. Usually payment systems let you specify URL where buyer will be redirected after successful payment.

{cancelUrl} — Add this placeholder if your payment system supports cancel URL. Usually payment systems let you specify URL where buyer will be redirected after canceling payment (or after payment was unsuccessful).

{verifyUrl} — Add this placeholder if your payment system supports payment verifying URL. Sometimes payment systems let you specify URL which will be called by payment system before callback URL in order to check if payment is not fake and really exists. Usually in this case payment systems require to output some message indicating of payment existence.

We can notice that parameter d_transactionid is added twice to the form when using payment system from Store widget — first time in "main.html" file and the second time in "main.php" file. To fix this problem we need to edit "main.php" file:

Also we can notice that parameter d_password is not added to the form at all. This parameter will be added to the form by PHP gateway payment class.

Adding PHP gateway payment class

In previous sections we managed to submit form to payment system when the form is used in Store widget. Now the form can send dynamic price taking it from Store and pass extra parameters like IPN URL needed for payment system to inform website about payment status. After that we need write logic which will handle IPN call on website and send appropriate response (if needed).

1. Create file "plugins/myplugin/site/GatewayMyplugin.php".Note: The name of the file should be constructed from concatenated words "Gateway" and your plugin name with capitalized first letter (e.g. if plugin name is "abc" then gateway class must be "GatewayAbc" or if plugin name is "abc_def" then gateway class must be "GatewayAbcDef").

The class must extend abstract class "PaymentGateway" which contains one required method "getTransactionId". All other methods are optional and should be used only if needed by payment system you are developing payment gateway plugin for.

We left all methods empty because the logic will depend on payment system requirements. Let's consider these methods in more details:

init — There can be any code for class initialisation. The method is called after class contructor.Note: This method must return boolean value. If it returns true then the payment will be set as successful. Otherwise the payment will be considered failed.

returnAfterCallback — Property indicating whether website must redirect client to Return URL right after Callback URL (IPN) was called and callback logic was processed.Note: Some payment systems prefer using separately return URL and callback URL. The client is redirected from payment system by return URL back to website (payment system → browser) and the callback URL is called later (payment system → server). In this case property "returnAfterCallback" must be false. Some payment systems prefer redirecting client back to website and pass payment status details at once with no separate IPN call. In this case property "returnAfterCallback" must be set to true.

getTransactionId — Must return value from request (POST or GET depending on payment system) of property which stands for transaction ID passed as parameter "d_transactionid" in form. This method is important because Store on website must identify payment by returned value. If Store does not find payment by transaction ID returned by this method it will not be able to set appropriate status to payment (complete,pending,failed).

createFormFields — Returns array of HTML inputs which should be embedded to the form right after a buyer submitted the form but the form has not been sent to payment system yet. The method accepts argument $formVars which is associative array containing serialized form information.Note 1: Some payment systems require calculating signature of values which are submitted. This can be done in this method and an extra form input returned.Note 2: If one of returned HTML inputs name matches name of already existing input in the form then that input will be completely replaced with returned in this method.Note 3: If you return boolean false then form will not be submitted.

createRedirectUrl — Returns URL which will be set to form "action" attribute. Some payment systems do not have static payment submiting URL. Intead they provide per merchant-basis URL or dynamic URL depending on form field values.

callback — The logic of callback. For example payment system might require to respond with some message which would indicate of successful IPN handling. In this case You can output any message like echo "OK"; (the message can be any depending on payment system). Note that you can also set your headers if payment system require (e.g. header('Content-Type: application/json; charset=utf-8');.Note: This method must return boolean value. If it returns true then the payment will be set as successful in Store. Otherwise the payment will be considered failed.

verify — The logic of payment verification. For example payment system might require to respond with some message which would indicate of payment existance. Otherwise payment system will not process the payment considering it fake. You can output any message like echo "OK"; (the message can be any depending on payment system).

In the class scope you can access property $this->config in any method. This is a property of type "stdClass" contains information stored in file "main.js" in property globalVars. For example in our Dummy payment gateway we can access our stored properties like this: $this->config->merchant and $this->config->password. Except our stored properties the object $config can also have these by default:

wbLang — 2-letter language code the website is currently on (set only if "Languages" widget is added in website).

wbDefLang — 2-letter language code of default site language (set only if "Languages" widget is added in website).

wbBaseLang — 2-letter language code of builder language the client was on while building website (always set).