open menu
axerve docs
Integration types/Standard payment page (PAGAM)

Standard payment page


This page provides details on the payment process via the standard payment.

How to process payments

  • Log in to Axerve Ecommerce Solutions Back Office

  • Recover the shopLogin

  • Set in the back office two endpoints for the positive/negative response and optionally the endpoint to manage the Server to Server notification.

  • Make a SOAP call to WsCryptDecrypt’s Encrypt method

  • Redirect the user to the standard payment page and wait for the payment to be processed

Descriptions of processing stages

A payment transaction consists of 4 basic stages, in which there is one or more communication steps. At each stage, the information necessary to process the transaction is exchanged between the various components.

Step I: Authentication and Webservice

The payment information is communicated to Axerve Ecommerce Solutions in order to be encrypted. To guarantee a high level of security, no sensitive information is disclosed to the buyer's server without prior encryption.


The authentication of the merchant's server requesting encryption or decryption services is performed by verifying:

  • Viability of the Shop Login: the ShopLogin parameter must correspond to a code registered in the customer details of Axerve Ecommerce Solutions

  • Server IP address: the server's IP address to which the request is sent must match one of the IP addresses configured in the merchant's profile

  • ApiKey: it is a unique token generated in the security section of the back office, and can be used to authenticate calls sent to Axerve's server

  • Shop Login status: the merchant status must be active (the status is managed by the Axerve Ecommerce Solutions administrator and not by the merchant).

If the authentication checks fail, a specific error is returned to identify the cause.

Please, check the following page to get more details regarding the possible error codesapi link.

At this stage, the merchant's server requests the encryption from Axerve Ecommerce Solutions, obtaining an encrypted code representing the transaction to be processed. The data identifying a transaction and its use are described in the API sectionapi link.


The WSCryptDecrypt web service is available both in production and test environment and does not require to be installed on the merchant's server.

The merchant must send a request to the web service managing requests to use the Axerve Ecommerce Solutions encryption service on of the virtual store pages set up to manage payments.

To activate the encryption service, you need to send a request to the Encrypt method.

If encryption is successfully carried out (meaning the value of the TransactionResult tag is OK), the code string encrypted by Axerve Ecommerce Solutions will be available under the value of the CryptDecryptString tag.

If the encryption process fails, ErrorCode and ErrorDescription tags values ​​will make it possible to identify the reasons why it could not be carried out.

For further details, please visit WSCryptDecrypt APIapi link .

Step II: Transaction Data Encryption

Some information is necessary to complete the payment process and therefore must be communicated to Axerve Ecommerce Solutions, while other data can be omitted without compromising the transaction process.

In Axerve's Back Office merchants can determine which information to consider necessary and optional.

The information essential and mandatory for the payment process is automatically configured by Axerve Ecommerce Solutions. These settings cannot be changed.

In WSCryptDecrypt API api linkpage you can find the complete list of fields as well as the list of mandatory information that must be communicated to Axerve Ecommerce Solutions XML using the Encrypt method in order to process the transaction. Tag names are case-sensitive.

Maximum length



ShopLogin given by Axerve Ecommerce Solutions.



Code that identifies the currency in which the total of the transaction is denominated (see Table of Currency Codes).



Transaction Amount. Do not enter the thousands separator. The decimals (maximum 2 digits) are optional and the separator is a dot.



Identifier attributed to the merchant's transaction.


The table above displays the required fields only. Other fields may be relevant if you use a specific anti-fraud system or alternative payments. Check the APIapi link for the full list.

There are two available endpoints:

  • Test environment link

  • Production environment link

You need to start with a SOAP encryption request, following which Axerve Ecommerce Solutions processes a payment with this data:

2   <shopLogin>GESPAY12345</shopLogin><!-- Assigned by Axerve Ecommerce Solutions backend --> 
3   <uicCode>242</uicCode> <!-- code for Euro --> 
4   <amount>1245.6</amount> <!-- the money you want to receive -->
5   <shopTransactionId>34az85ord19</shopTransactionId> <!-- an ID generated by you -->

Axerve Ecommerce Solutions responds as follows:

2   <GestPayCryptDecrypt xmlns="">
3   <TransactionType>ENCRYPT</TransactionType>
4   <TransactionResult>OK</TransactionResult><!-- everything ok! -->
5   <CryptDecryptString>2C53F1B5...</CryptDecryptString><!-- crypted string with sent info -->
6   <ErrorCode>0</ErrorCode><!-- ...another way to say Ok! -->
7   <ErrorDescription/>
8   </GestPayCryptDecrypt>

With the string encryption (2C53F1B5...) and the shopLogin it is possible to redirect the user to the payment page.

Step III: request to the payment page

After obtaining the encrypted data code (as described in the previous step), the buyer will be redirected to the payment page of the Axerve Ecommerce Solutions server to the following address:<ShopLogin>&b=<encrypted string>

in test environment:<ShopLogin>&b=<encrypted string>

The page request will be executed by satisfying two parameters:

  • a The code that identifies the merchant (Shop Login)

  • b The encrypted code string that identifies the transaction

The payment page receives the parameters and verifies the identity (parameter a must correspond to the merchant) and the security of the transaction data (parameter b must correspond to the string of encrypted data communicated by the merchant during the previous step).

If the checks are passed, the buyer will see the payment page and will have to enter the required data to complete the payment process.

If the checks are not passed, the payment page will not be displayed and the process moves on to the next step of the communication of the transaction result.

Via our payment page :

  • Axerve manages transaction security

  • You can choose which active payment systems will show in the list, such as PayPal, UnionPay or MyBank

  • You can customize the layout by inserting your own logo

Step IV: communication of the result of the transaction

After the buyer has concluded the payment, Axerve communicates the result of the transaction to both the merchant and the buyer.

The payment result for the merchant

Once the payment has been successfully carried out, Axerve Ecommerce Solutions redirects the user to the URL set up for a positive response. Otherwise, it will be redirected to the URL created for the negative response.

Redirecting happens according to 2 parameters:

  • a which is the shopLogin

  • b which contains an encrypted string with the transaction result

At this stage, the merchant's server must send the request WsCryptDecrypt.Decryptapi link again to decrypt the gateway response and show the correct message to the buyer.


On the same response has been set up for both positive and negative results, but it is still possible to set a specific response for each result. The buyer is redirected to:


response.php page needs to be able to:

  • receive 2 arguments (a & b)

  • decrypt b

  • show the buyer the outcome (receipts, emails etc.)

Once the payment is completed, Axerve Ecommerce Solutions communicates an encrypted string with the transaction result to the merchant's server via Server to Server URL (optional). If the Server to Server URL has not been set up in the back office, the communication will take place on the URL defined for a positive response.

The notification is forwarded by server-to-server request to the page specifically set up on the merchant's server (the URL of the notification page is one of the merchant's profile data, and is configurable through Axerve Back Office). The syntax of the call is as follows:

http://<url server to server>?a=<ShopLogin>&b=<encrypted string>

The request to the page is sent after 2 parameters are satisfied:

  • a the code that identifies the merchant (Shop Login)

  • b the encrypted code string with the transaction result

If there are any communication errors, Axerve Ecommerce Solutions will perform multiple forwarding attempts for two days following the transaction.


Once a and b are received, you can send the Decrypt request (from the WsCryptDecrypt web service) to find out the outcome of the transaction and update the database, in order to send the confirmation email to the customer, etc.

The merchant will also receive an e-mail notification regarding the result of the transaction to the address set up in their profile.

Furthermore, the processed transaction can be viewed by accessing the Axerve Back Office in the Active Report section.

According to the MOTO settings, the transaction can be set to Authorized (the amount of the transaction is blocked but not yet transferred); or Settled (MOV – the amount is transferred from the buyer's account).

If the transaction is authorized, it must be captured in the Axerve Back Office.

Payment result for the buyer

Axerve Ecommerce Solutions immediately communicates the result of the transaction. The buyer can also download the receipt in PDF format.

The buyer will also receive an notification email with the transaction result to the address provided on the payment page, if indicated.

At the end of the payment, if the buyer does not click on the "Back to shop" button, the payment will not be finalized and the Axerve's server will not send the Server to Server notification to the merchant.

prevIntegration types