Introduction

Version

This documentation covers the lynck system version 3.9.0.

Intended Audience

This documentation is for merchants and developers who want to implement the lynck payment system. Help us improve this guide by contacting us and pointing out errors, misspellings or unclear sections at service@lynck.de.

Getting started

Lynck offers an interface for web-shops to integrate with a variety of payment options by performing just a single integration with the lynck system. Integration with lynck spans into the various shop processes and systems from web-shop to warehouse to accounting.

The lynck interface is suitable for both immediate fulfilment – for example, for transactions involving electronic services or goods that are delivered immediately after the checkout took place – or delayed fulfilment – transactions involving goods ́ delivery (order delivery) to users after a time, possible days from checkout.

So lynck allows the shop to focus on the best shopping experience for its users without having to deal with the hassle of providing a variety of payment options and multiple integrations. The implementation of the multitude of payment options can be realized with just one integration. During checkout, lynck’s payment system is optimized to select the most convenient payment options for the shop’s customer and at the same time satisfy the shop’s needs for secure payments.

Integration options

The lynck platform offers great flexibility for the integration into the web shop's checkout process. In general, there are two types of integration for two versions each. This allows E-commerce merchants with any sales volume to choose the ideal integration type for their requirements.

Identifier	Type	Description	Benefit
API	API	The lynck System is integrated as pure backend API solution without using a Hosted Page or any frontend elements. To transfer credit card data the merchant has to be PCI compliant.	Full design control, seamless page tracking
SecureFields	API with using secure fields	The lynck system is integrated as an API solution using the lynck Secure Fields to transfer credit card data in the shop frontend.	Full design control, seamless page tracking, drastically reduced PCI requirements
HostedPageBefore	PRE-integrated Hosted Page	The Hosted Page, which shows all payment methods/instruments is integrated before the confirmation page of the merchant's shop is shown. The hosted page allows the user the select a payment method and enter payment instruments like credit card and bank account.	Less effort required for frontend integration, drastically reduced PCI requirements
HostedPageAfter	POST-integrated Hosted Page	The Hosted Page, which shows all payment methods/instruments is integrated after the confirmation page of the merchant's shop is shown. The hosted page allows the user the select a payment method and enter payment instruments like credit card and bank account.	Less effort required for frontend integration, drastically reduced PCI requirements
HostedPageAfter	Pay By Link via API	The lynck System creates a payment link which redirects the customer to a hosted payment page to complete the payment.	No integration into the shop front-end required, drastically reduced PCI requirements

API integration

When using complete/self-sufficient API integration, the E-commerce merchant has maximum flexibility when designing and integrating the payment page, but in return he has to fulfil the high security requirements imposed by e.g. PCI-compliance guidelines issued by credit card companies. This integration type is therefore more suited to large companies which want to retain full design and process control.

API integration with secure fields

The API integration with secure fields corresponds to the aforementioned version, however, with the difference that the secure fields library is made available to the E-commerce merchant via the lynck platform. This solution is used to handover credit card and bank details in a secured environment outside of the shop sovereignty and avoids that the E-commerce merchant has to independently fulfil the PCI-compliance guidelines issued by the credit card companies. This integration type therefore tends to be more suited for large companies which want to retain full design and process control yet avoid more strict PCI-requirements.

Integration as Hosted Page (Before / After)

Lynck delivers a complete payment page with the easy and above all fast "Hosted Pages" integration type. It is a complete payment page for all payment types for the E-commerce merchant's shop and ensures that no safety relevant data is stored on the retailer's website. Therefore, the E-commerce merchant automatically fulfils the applicable high safety standards e.g. PCI-compliance imposed by credit card companies.

The standard Hosted Page design is responsive, i.e. depending on the end customer’s terminal (e.g. PC, smartphone or tablet) the payment page is optimised for the terminal's display. A special feature is the easy customization of the Hosted Page: It can be configured independently by the E-commerce merchant which allows them to retain in parts control over the page design. Changes can be checked with the preview function and set "live" with one click. In addition to the visual design of the payment page, the E-commerce merchant can also make content changes. This allows shops to provide individual, multi-lingual texts for every payment method (e.g. as explanatory note or to promote individual payment methods) and to save individual fees or discounts per payment type. This also enables the retailers to have significantly more control with regard to directing the end customer to certain payment methods.

The E-commerce merchant can also specify the point at which the payment page should be shown during the entire checkout process. There is a choice of "before" or "after" purchase confirmation, referred to as the pre-integration (3) or post integration version (4). Therefore, the Hosted Page can be ideally integrated into the checkout process according to the needs and preference of the E-commerce merchant.

Pay By Link integration

Pay By Link via API allows the creation of payment links directly from the merchant's system. These links can be used/delivered in any way to allow customers to pay in an fast and easy fashion. Optionally the lynck system can be instructed to automatically send these payment links in an email to the customer, which further reduces the implementation effort. The payment link redirects the customer to a payment page which is based on the 'Hosted Page After'. Pay By Link transactions require a minimal amount of parameters to be initiated compared to other integration options. Should solvency checks be performed for payment methods such as bill payment and direct debit, the necessary data for the check will be collected on the payment page directly from the customer. This integration type is not meant to be used in a shop checkout, but as an alternative way to collect payments independent of any shop. Possible use cases include, but are not limited to, mail and telephone orders, or offering alternative payment methods on the bill for a customer.

Process description

To understand the lynck system some terms and correlations need to be explained. The following graphic illustrates the relation between transactions and captures

Transactions

If a user initiates the payment process within the checkout process, the merchant’s shop system performs a createTransaction call in the lynck system and transfers all relevant data. A transaction can be referred later on by the shop system (or an ERP system) with the unique identifier orderID. This could be the reference number of the order or an invoice number or anything else, but is has to be unique for the shop. After receiving all necessary data, the lynck system creates a transaction with the status New. The transaction will then pass through different states which are represented by the transaction status.

Status	Description
New	Internal status. Means that a transaction has been created within the lynck system after receiving the user and basket data from the shop system during checkout.
AcknowledgePending	Internal status. The user has confirmed the purchase during checkout by pressing button "Buy" and in case of redirect payment methods lynck is waiting for the response from the shop which contains the success-URL.
FraudPending	This status indicates, that the transaction is suspect due to fraud suspicions and needs to be reviewed manually.
CIAPending	The transaction was created successfully and lynck is waiting for funds to arrive or become available. Relevant for payment methods: AMAZON_PAY, PAYPAL, PREPAID, ZINIA_BNPL, ZINIA_INSTALLMENT
MerchantPending	The transaction was successful. Lynck is waiting for the merchant to capture the transaction when delivering the order or immediately after the checkout process.
InProgress	The transaction was captured successfully. The transaction will remain in this status until all captures are in status paid.
Expired	The transaction was not completed by the user within the duration of the basket-validity.
Cancelled	The transaction was cancelled by the merchant.
FraudCancelled	The transaction was cancelled due to fraud. This can occur if they were in status FraudPending and then declined by the merchant or lynck, or if the merchant reported the user as fraudulent in the MSA or using the reportFraudUser API.
Done	The transaction has been completed. A transaction will change into this status if all of its captures have the status paid.

The transaction status can be affected by the user, the system, the fraud team, the shop or the capture status.

The transaction status remains as New until a reservation is made. This usually happens when the customer clicks the "Buy" button on the web-shop. After confirmation of the purchase the transaction status changes to AcknowledgePending.

The resultCode of a reservation is 0 in case of a successful reservation, but it can also equal 1 regarding of the payment method. This signals that the user needs to be redirected to a payment page of a third party payment supplier (e.g. PayPal). The URL to which they should be redirected is provided by lynck in the response to the reserve call.

After the reservation has been confirmed, the status of the transaction is set to MerchantPending in case the funds are ready to be captured or CIAPending in case the funds are still pending. After the funds have become available the transaction status changes to MerchantPending.

If the shop/ERP system cancels the transaction via cancel call, the status of the transaction is set to Cancelled. If any funds were received before a capture was performed, the lynck system will automatically initiate a refund.

Captures

All transactions with status MerchantPending wait to be captured by the shop/ERP system. A capture can be referred later on by the shop/ERP system by passing the unique identifier captureID via capture call. So whereas the creation of a transaction is triggered by the user during checkout process, the creation of an capture is initiated by the shop/ERP system.

Status	Description
PayPending	The capture or partial capture is waiting to be paid.
Paid	The capture or partial capture was paid successfully. Alternatively the open amount could have been reduced to 0 using a refund on bill and direct debit transactions.
PaymentFailed	This status indicates that the payment failed.
Cleared	The capture or partial capture was booked successfully and cleared.
Chargeback	A chargeback was reported on the capture.
InDunning	This status can only occur if the dunning and collection service has been enabled at lynck. Customer is in the dunning process.
InCollection	This status can only occur if the dunning and collection service has been enabled at lynck. Customer is in the collection process.

The point of time when a capture should be done, depends on the business model:

• shops that want to charge the user with delivery perform the capture as soon as they have delivered or trigger the delivery(more user convenient)
• shops that want to charge the user immediately after ordering - either if they deliver their goods afterwards or because they sell digital goods - will perform the capture directly after a successful transaction creation

Lynck also supports the ability to perform more than one capture e.g for the case of partial delivery.

After a successful capture the status of a transaction is set to

• Done as soon as lynck received funds from the user for the capture so that the capture has the status Paid. In case of several captures the transaction status will be set to Done as soon as all captures are in status Paid
• InProgress when lynck waits for incoming funds (e.g. invoice or direct debit) so that the capture has the status PayPending

The transaction status is therefore dependent on the action of the shop/ERP system up to a certain point in time. As soon as the shop/ERP system creates one or more captures for a transaction, the transaction status will be directly affected by the status of those captures.

Example: If a capture was created for a transaction and the capture was marked as Paid, the transaction status is Done as the capture status is Paid. If a chargeback is reported by the bank or credit card company, the capture status changes from Paid to Chargeback and therefore the transaction status changes back from Done to InProgress. It is possible for the transaction status to move in either direction.

If the merchant does not want to capture the full amount, e.g. because some goods can not be delivered, the finish call should be used to close the transaction. This will refund the overpaid/uncaptured amount to the user in case the transaction was paid in advance, but keep all captured funds.

User

Users will automatically be created at lynck when createTransaction is called with a new userID. Alternatively registerUser can be used to create users without starting a transaction each time. The userID is the unique identifier of a user for a specific store. If a returning user for a store is identified by lynck using the userID, any payment instruments stored for this customer will be displayed when using the hosted pages integration type. This allows returning customers to re-use cards/bank accounts without the need to re-enter all data. Due to the sensitive nature of this data the merchant has to make sure that no userID can be shared between users.

Hosted Pages description

Types of Hosted Payment integration

There are two ways to integrate Hosted Pages. The payment page can be shown before or after the shops order confirmation page. Which option fits better depends on the used web-shop or module.

Hosted Pages Before

1. With the API call createTransaction the shop passes all relevant data to lynck
2. The lynck system returns a URL, which refers to the hosted payment selection page. The shop displays the hosted payment selection page to the user and lynck performs the first risk check before displaying the selectable payment methods
3. The user selects a payment method on the payment selection page, and enters the payment instrument data if necessary
4. In case of an error the lynck system shows the error message on the payment selection page
5. The lynck system redirects the customer to the confirmation URL configured for this shop and informs the shop about the selected payment method. See: callback
6. The shop calculates the final order amount and displays the purchase confirmation page to the user. After the user confirmed the purchase, the merchant reserves the final order amount with the reserve call
7. In case of an error the lynck system returns a new URL in its response with the proper error message and the shop redirects the user back to the updated payment method selection page
8. In case of a positive outcome for the risk check the processing of the payment can start

Hosted Pages After

1. With the API call createTransaction the shop passes all relevant data to lynck
2. In case of an error the lynck system shows the error message on the payment selection page
3. The lynck system returns a URL, which refers to the hosted payment selection page. The shop displays the hosted payment selection page to the user and lynck performs the first risk check before displaying the selectable payment methods
4. The user selects a payment method on the payment selection page. Lynck now validates the data and performs the second risk check
5. In case of an error the lynck system shows the error message on the payment selection page
6. In case of a decline due to a failed second risk check the lynck system shows an error message on the payment selection page
7. In case of a positive outcome for the risk check lynck automatically reserves the full transaction amount. The merchant does not need to perform the reserve call themself

Risk Management

The integrated risk management platform uses a combination of machine learning, sector specific data and fully adjustable criteria in order to decide in real time whether transactions are accepted or rejected, if the end customer only gets offered secure payment methods or if the transaction has to be checked manually. Buyers shopping with online retailers can pay for their goods, services and digital contents using a range of payment methods such as credit cards, PayPal, direct debit, prepayment etc. The payment methods vary in cost and risk (with regards to non-payment risk) for the online retailer on the one hand and with regard to popularity with the customers on the other. If a preferred payment method is missing, then it may lead to an increased rate of purchase cancellations and reduce the so-called retailer conversion rate.

The risk management integrated in the lynck platform controls the payment types for E-commerce retailers actively and dynamically during checkout based on different check algorithms and criteria based on select parameters.

Dynamic control is carried out based on a two-step risk assessment. In advance, it is coordinated with the merchant which payment methods should be available in general and which of those are offered for certain risk assessments.

As seen in the graphic above, the process starts with the merchant initiating a createTransaction request when the customer enters the payment section of the checkout. Using this request the merchant can already decide how to treat the customer based on his own experience. This allows the merchant to:

• Offer all payment methods to VIP customers or business partners without any risk checks taking place. (Trusted customer - low risk)
• Offer only secure payment method to customers known to cause issues or who are suspicious. (Suspicious customer - high risk
• Let lynck decide whether the customer should be treated as high risk customer based on configured risk settings and provided data. (Unknown customer - medium risk)

Furthermore, the merchant is able to provide risk classes for basket items as well. Similar to the first level risk assessment done by lynck, these will only apply if the transaction risk class is medium. See the following table on how the combination of customer and basket items risk class affect the transaction risk class:

Extended Risk Classes

Instead of only providing the main three risk classes low(0), medium(1) and high(2), it is also possible to provide user risk classes with a decimal point from 0-2. This way merchants gain access to a more finely grained risk management of customers in the checkout process based on their past experiences with them.

By default all risk and solvency checks are performed in the risk class range from 0.1 - 1.9. Specifically for limit, velocity, open debt rules and all solvency checks it is possible to define risk class thresholds, which define at which risk class a rule or check becomes active. This means that multiple rules or checks with different thresholds can be configured, whereas the rule/check with the highest threshold that is reached will be applied.

The extended risk classes allow: * Application of different limit, velocity and open debt rules depending on the customer risk class * More control over the offered payment methods for each risk class * Usage of different solvency check products depending on the risk class * Different solvency check result interpretation depending on the risk class

Setting Risk Classes On Customer Level

While setting customer risk classes and basket item risk classes during transaction creation may allow to fully manage the risk level of transactions, it may not always be feasible to modify these for individual customers, depending on how the solution is integrated into the shop.

As an alternative it is possible to directly assign a risk class to any individual customer registered in your shop. This risk class is then stored for this customer, until it is either updated or deleted. When a transaction is created for a customer, which already has a risk class stored, then this stored risk class will always take priority over any other risk parameters provided during transaction creation. This feature can be used to effectively white- or blacklist individual customers without changing any logic related to transaction creation in your system.

To directly assign a risk class to a customer, the parameter userRiskClass can be set when using the API endpoints registerUser or updateUser. Alternatively it can be manually assigned when adding/editing a customer in the lynck hub.

Dunning and collection

Every German and Austrian shop has the option to use the professional dunning and collection service of our partner Accredis.

All orders will automatically be passed to Accredis for processing

• if the due date is reached in case of unpaid bill transactions
• if a direct debit payment bounced.

All orders, which have been passed to Accredis, go into status inDunning. Also the user/debtor gets this status.

If a user is in status inDunning, they are (per default configuration) unable to pay with insecure payment methods like direct debit or bill until they have paid the outstanding amount.

If the dunning process was successful or the Accredis file gets closed, the lynck system is notified about it.

In this case the status of the order will be set to paid even if the debt claim was not fully paid. A file can be closed if the user was not able to pay or just paid a partial amount of the debt claim.

If the dunning process finished without the file being closed as mentioned above the collection process starts. Accredis notifies lynck about the start of the collection process, which triggers the order and the user status to change to inCollection. Similar to inDunning customers with status inCollection will not be able to use insecure payment methods. The order will only switch to paid if the file is closed manually, or an incoming payment is registered.

All orders with status paid will be passed to the clearing, so that the shop gets all payments which have been collected during dunning/collection.

To effectively use this service Accredis at least requires the invoice number of the order created by the merchant. The invoice number can either be passed to lynck and therefore Accredis by providing it in the field captureID when performing a capture, or alternatively it can be passed after capturing by using the updateInvoice.

Implementation Details

General Rules

Data Types

Following data types are used in this documentation:

Type	Description	Comments	Sample
AN (length)	Alpha-Numeric	Sequence of characters (UTF-8 encoded) with maximum length	Test
N (length)	Numeric	Sequence of numbers with maximum length	12356
V	Fixed Value	The possible values can be found in the comments	CC
J (type)	JSON-Object	JSON object of a special type	{ 'id': 'xyz' }
JA (type)	JSON-Array	Array of JSON objects of a special type	['abc', 'xyz']
B	Boolean value	true or false	true
D (format)	DATE	Date with a specified Format like YYYY-MM-DD	2020-02-22

Security and signing of requests

In order to ensure the security of the calls made to the lynck interface, there are certain rules that have to be followed.

• All calls have to be made via HTTPS.
• All parameters shall be passed via POST requests
  • The requests should be sent with Content-Type "application/x-www-form-urlencoded" if not described otherwise in the API
  • The responses will have Content-Type: "application/json"

In order to prevent any tampering with the parameters of the request, all calls have to be signed with what is known as a Message Authentication Code (MAC).

The MAC has to be calculated by the caller and passed along as a further parameter in the request. The algorithm used for this is HMAC (RFC 2104). The HMAC algorithm needs to be a shared secret between parties in order to validate the authenticity of the message. All responses from lynck contain a MAC in the response header which can be used for validation.

Status codes

Successful responses have HTTP status 200 (OK). If there is a problem with the content of the request the http status is 400 (Bad Request). In case of validation errors there is a http status 401 (Unauthorized) returned. Possible causes are:

• wrong or missing merchantID
• wrong or missing storeID
• wrong or missing MAC
• request to a non existing endpoint

Merchant credentials

• The merchant ID you will receive when getting access to our sandbox or production environment acts as a container for shops/stores, meaning a merchant ID may be related to multiple store IDs. Your private key is only valid for this merchant ID and all stores below it.
• Each store ID is bound to exactly one currency. Usually the ID contains the ISO 4217 currency code that it is bound to. For example: teststoreEUR. This means if a single store front-end supports multiple currencies it will require multiple store IDs. For each currency the calls will have to be made with their respective store ID.
• Each store ID is bound to exactly one confirmation, success and failure URL respectively. These URLS are the targets for callbacks which are performed synchronous to the payment process. For more information see: Callback documentation
• Each store ID can be assigned multiple notification-URLs. This URL is the target for transaction status updates. For more information see: Notification documentation
• Risk settings such as velocity rules, blacklists and solvency checks can be configured for each store ID.

MAC calculation

The Message Authentication Code (MAC) is used to ensure data integrity and therefore includes the request parameters with further calculations performed.

The MAC is included in both the request and response.

Request

In requests the MAC is sent as POST parameter

Response

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
X-Payco-HMAC: 289740cfda1c7f1df1c2ce9562930350e6bcb0a6
Transfer-Encoding: chunked

In the response the mac is part of the HTTP header as X-Payco-HMAC

There are cases where the lynck system can not generate a MAC. For example if the merchantID is missing in the request and the merchant can not be identified. In this case there will be no MAC in the header. This will only happen for error-messages (resultcode 101). Responses for successful calls will always include a MAC

Calculation

The MAC should be computed as follows:

Generate an HMAC-SHA1 key using the merchant's private key. The key can be computed once and stored if the private key is unchanged.

Request

Create the datastring. Build a string containing the calls parameter values alphabetically ordered (a - z). To order the parameters the key is used and not the value. The parameter "mac" is the only one that is not included in the calculation.

• The included strings' parameter values should be identical to the ones sent in the request or received in the response
• If a parameter value is sent as empty, or the parameter is not set at all, then related parameter value for MAC calculation can be an empty string ('') or simply not included at all.
• The datastring should not include any spaces or non-printable control characters ( \n, \r, \t, \f, \v space ), which can easily be found with the regular expression meta character '\s'. Remove all the non-printable characters from the datastring.

Compute the MAC using the HMAC-SHA1 calculation together with the private key on the datastring.

Response

In the response the whole body is the datastring as it contains all the payload, but the process is exactly the same as outlined in the previous paragraph. Keep in mind to remove the parameter 'mac' from the response before calculating and verifying its MAC.

To validate notifications sent from lynck to the merchant, the process is basically the same as described above.

Example

<?php
function getMac($request) {
    global $privateKey;

    // Sort parameters alphabetically by key for MAC calculation
    ksort($request);

    // Create a string from the parameter values for MAC calculation
    $macstring = implode("", $request);

    // Calculate MAC
    return (hash_hmac('sha1', str_replace(array(" ","\t","\s","\r","\n",' '), "", $macstring), $privateKey));
}
?>

import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;

public class MACCalculator {

  public String calculateMAC(String input, String secret) {
    // generate MAC Secret Key (Step a)
    Mac mac = null;

    try {
      SecretKeySpec signingKey = new SecretKeySpec(secret.getBytes(), "HmacSHA1");
      mac = Mac.getInstance("HmacSHA1");
      mac.init(signingKey);
    } catch (Exception e) {  /* handle exception*/}
    return hmac(input, mac);
  }

  // method that applies mac key to the parameters string
  private String hmac(String input, Mac mac) {
    input = input.replaceAll("\\s", "");

    final byte[] hmac = mac.doFinal(input.getBytes());

    final StringBuilder hex = new StringBuilder(2 * hmac.length);

    for (final byte b : hmac) {
      // b & 0xff converts e.g. 0xffffff81 to 0x81
      String hexString = Integer.toHexString(b & 0xff);

      if (hexString.length() < 2) {
        hex.append("0");
      }
      hex.append(hexString);
    }
    return hex.toString();
  }

  public String calculateAndGetMAC(MultiValueMap<String, String> map, final String merchantPassword) {
    StringBuilder macInput = new StringBuilder();
    SortedSet<String> keys = new TreeSet<>(map.keySet());
    for (String key : keys) {
      String value = map.toSingleValueMap().get(key);
      macInput.append(value);
    }
    return calculateMAC(macInput.toString(), merchantPassword);
  }

  /*
  * Main method only includes a simulation to a MAC Calculator client
  */
  public static void main(String[] args) {
    String merchantPassword = "8A!v#6qPc3?+G1on";

    // The input variable below should include the call parameters in alphabetic order
    String input = "123testOrdertestStore";

    MACCalculator macCalculator = new MACCalculator();
    System.out.println((macCalculator.calculateMAC(input, merchantPassword)));
  }
}

To verify if the MAC calculation is implemented properly, please find following sample strings and the respective correctly calculated MAC value:

Assume merchant private key value here is: 8A!v#6qPc3?+G1on

The request is a cancel call with following parameters:

key	value
merchantID	123
storeID	test Store
orderID	testTransaction

Ordered alphabetically:

key	value
merchantID	123
orderID	testTransaction
storeID	test Store

Remove special delimiters:

key	value
merchantID	123
orderID	testTransaction
storeID	testStore

The concatenated parameter string is:

123testTransactiontestStore

The resulting calculated MAC should be:

7aea4cc6313b2814053488079563375bf1544663

API Throttling

To prevent abuse of the API and ensure stability there are restrictions in place which limit the rate of requests per timeframe that can be performed to the lynck system.

Any given API endpoint has an assigned request pool which represents the amount of requests which can be made before the API rejects any further requests. This request pool refills with a set rate and therefore allows for a short burst of multiple requests at once, but limits the overall requests that can be made over longer periods of time.

The size of the request pool and the refill rate may depend on the specific API endpoint and the system which is called. Request pools and the refill rate are independent for each individual API endpoint. For example, even if the limit for the getTransactionStatus API is reached, the createTransaction API would remain unaffected.

Callback

Callbacks are redirects of the customer back to the shop performed by the lynck system to the URLs configured for the merchants shop. For each shop one confirmation, success and failure URL can be defined.

The following GET parameters can be added to the URLs:

Field	Type	Mandatory	Comments
-MERCHANTID-	N 16	yes	This is the merchant ID assigned by lynck.
-STOREID-	AN 60	yes	This is the store ID of a merchant assigned by lynck as a merchant can have more than one store.
-ORDERID-	AN 30	yes	This is a unique identifier for a transaction which is created by the shop.
-MERCHANTREF-	AN	no	Reference, that additionally can be set by the shop. This parameter is sent back with every call from lynck to the shop
-PAYMENTMETHOD-	V	yes	The identifier of the payment method. See PaymentMethods
-LOCALE-	V	yes	The locale determines the user’s communication language e.g. for e-mails which will be send to the user or for payment pages. See Languages
-PI-	AN 20	no	The unique ID of the payment instrument. This ID is created by lynck.
-MAC-	AN 20	no	Message Authentication Code. See: MAC calculation

Confirmation

After a customer selected his payment method on the hosted page he will be redirected to the confirmation URL. This allows the merchant to display the selected payment method on his order confirmation page and change the final order amount accordingly if required.

Example of a confirmation URL: https://www.example.com/testshop/confirm?merchantID=-MERCHANTID-&storeID=-STOREID-&orderID=-ORDERID-&paymentMethod=-PAYMENTMETHOD-&paymentInstrumentID=-PI-&mac=-MAC-

Successfull payment

For all payment methods which redirect the user to a different web-page the lynck system redirects the customer to the success URL of the shop, in case of a successful payment. For integration type HostedPageAfter this redirection will take place for all payment methods. The available GET parameters for the success URL are identical to those of the confirmation URL.

Example of a success URL: