Micropayment Payment Methods

1. Introduction

The following document provides an overview of the payment options offered by micropayment™ and intends to serve as a guide for their integration.

return to the top

2. Integration

All payment windows are located at the following URL: https://{Pay-Domain}. The payment modules and services are accessed with the following URL format:

https://{Pay-Domain}/{Modul}/{Service}/

The following payment modules are currently available. These modules must be activated and configured beforehand in the Payment Configuration.

Domain of payment {Pay-Domain}
Call2Pay call2pay.micropayment.de
HandyPay mobilepayment.micropayment.de
SEPA direct Debit sepadirectdebit.micropayment.de
CreditCard creditcard.micropayment.de
SOFORT Überweisung directbanking.micropayment.de
PrePay prepayment.micropayment.de

call2pay

Payment by telephone. The customer is requested to call a toll number. The fee is set on a per-call basis for the desired payment amount.

handypay

Payment via cellular phone bill. The customer enters his or her cell phone number and receives an SMS with a TAN in order to confirm payment.

sofort

Payment using SOFORT Überweisung online banking. The customer transfers the payment amount his or her online banking access and a TAN. After making payment, the customer receives access to the purchased product.

creditcard

Payment per credit card. The customer enters his credit card data and confirms the transaction. The transactions can be optionally carried out with the 3-D Secure™ method (verified by VISA™ and Mastercard SecureCode™).

lastschrift

Payment by direct debit. The customer enters his or her IBAN and BIC and confirms the direct debit authorization.

prepay

Pay by bank transfer. Fully automated payment system. No registration for customers


For each module the following payment services are available:

file

Purchase of an online document. After completing payment the customer is given the option of viewing or downloading the desired document. Data security is provided by micropayment's patented proxy technology.

event

The purchase of credit, access, and products, etc. The operator is informed of the transaction by means of a third connection, and can redirect the customer in a targeted fashion.

All payment options can be easily integrated with a link at your website. The payment window can be opened as a pop-up, new window, or in a frame at your website.

<a target="_blank" href="https://{Pay-Domain}...">New Window</a>
<a target="_blank" href="https://{Pay-Domain}...">Same Frame</a>
<a href="javascript:window.open('https://{Pay-Domain}...','','');">As Pop-up</a>

All data governing the behavior and appearance of the payment window, as well as payment information, are transmitted to the payment window via parameters.

return to the top

3. Sending the Parameters

All parameters can be attached to the payment window URL (using the GET method), or sent to the URL (using the POST method). Both of these methods can be used at the same time, however, parameters sent with the POST method have precedence.

<!-- Sending with GET -->
  <a href="https://{Pay-Domain}.../?param1=wert&param2=wert&...">Query with GET</a>

<!-- Sending with POST -->
  <form name="payment" action="https://{Pay-Domain}.../" method="post">
    <input type="hidden" name="param1" value="value">
    <input type="hidden" name="param1" value="value">
    ...
    <input type="submit" value="Query with POST"
  </form>

If address data is sent for automatic debt collections, we advise sending the data with the POST method, as the length of the URL with GET parameters is limited. Please also consider the fact that the URL (with attached parameters) will be saved in log lists as it makes it way through various servers and routers in the Internet. Third parties cannot intercept sensitive data, however, when data is sent per POST via a secure transmission protocol (HTTPS).

return to the top

4. Parameters

4.1. Project, Webmaster and Campaigns

The parameters control the assignment of the payment to your project, webmaster and campaign.

project

The parameter determines which project settings should be used. The parameter is required and must contain the project code from the Project Configuration.

(account)

If you would like to make use of micropayment's affiliate options, the account of the webmaster can be entered here. The webmaster's account receives a certain share of revenues depending on the entered settings. The account of the project owner is used by default.

(projectcampaign)

This parameter allocates the revenues to a specific campaign. This must be created and activated in the ControlCenter. The campaign ID is entered here.

(webmastercampaign)

The parameter behaves like the projectcampaign parameter, except here the webmaster must enter one of his or her campaigns.

return to the top

4.2. Amounts, Products, Booking Texts

Details about the purchase are governed by the following parameters. In the Configuration you can determine if the inputs under title and amount are fixed values, which will cause the parameters to be ignored. If these inputs are not fixed, we strongly recommend you activate the expanded security features for the payment service. All parameters in this category must then be encrypted and cannot be manipulated.

(title)

This parameter contains the description of the offered product, e.g. the product description or order number. For the "File" payment service, this parameter identifies the file name of document that the customer can download after payment. If no input is provided here, the standard product setting from the Payment Method Configuration will be used.

(paytext)

With this parameter the reason for payment can be indicated for bank or credit-card payments. The name of the project combined with the title parameter is used by default for the payment text.

(amount)

The amount to be paid is determined with this parameter. The amount indicated is always in euro cents. The standard price from the Configuration is the value used by default for each payment method.

(userid)

Some payment methods support repeat customer purchases. Using this parameter, return customers are recognized automatically. This dispenses with the need to re-enter all required data. In order to prevent abuse, the encryption of this parameter is necessary, as the customer will be shown his or her saved private data.

return to the top

4.3. Layout, Color and Graphics

(theme)

Using this paramter an alternative layout for the payment window can be selected. Micropayment offers a selection of layouts for most payment methods. The "Default" layout is displayed standard.

(bgcolor)

This parameter is used to indicate the background color of the payment window. The payment frame, for example, can thus be optically integrated with your website. The automatic setting for this paramter depends on the selected layout.

(gfx)

Some of the layouts that are offered support the integration of custom logos and graphics. These logos and graphics must be uploaded beforehand in the ControlCenter; the parameter will also indicate the name of the desired logo/graphic. Micropayment offers a range of additional images aside from the standard graphics. A complete list is available at the Payment Generator.

return to the top

4.4. Customer Address Data

The customer's address data is sent using the following parameters. This address data is required to start an automatic collections process in the event of non-payment. Payment methods and settings that are automatically queried from the customer are saved and displayed by default and the customer only needs to edit them as necessary.

(mp_user_email)

The e-mail address of the customer

(mp_user_firstname)

First name of the customer

(mp_user_surname)

Last name of the customer

(mp_user_address)

Street and house number of the customer

(mp_user_zip)

ZIP/postal code of the customer

(mp_user_city)

City of residence

(mp_user_country)

Country in form of two-digit country code in accordance with ISO 3166

return to the top

4.5. Parameters Related to Payment Methods

Some payment methods additionally support the following specific parameter inputs:

4.5.1. Direct Debit

For direct debit payments, the following data is requested from the customer using a form. However, automated form entries for the following parameters can be made.

(mp_dbt_accountholder)

Parameter for the account holder

(mp_dbt_iban)

Parameter for the customer IBAN

(mp_dbt_bic)

Customer bank BIC

return to the top

4.6. Seal

(seal)

The parameter contains the seal of all sent parameters that precede it. It can be generated in the ControlCenter with the Seal Generator or by using a server script at your own website. If additional parameters are entered behind seal, the seal remains unchanged. In this way, the URL (with all values and seals relevant for payment) can be sent to the webmaster so that he or she only needs to attach the URL to his or her webmaster account.

return to the top

4.7. Free Parameters

(free_...)

Any number of desired parameters can be added to the payment windows and forwarded to the target document (the "File" payment service) or API URL (the "Event" payment service). In the Configuration the corresponding placeholders "__$free_...__" can be used for this purpose. In order to avoid conflicts each parameter should contain the prefix free_.

return to the top

5. Encryption

The activation of expanded security features and the encryption of the sent parameters ensure that the accessed payment window is immune to manipulation. This is achieved by the following:

  1. The parameter portion of the URL includes a secret access key.

  2. An MD5 hash is generated for the string as a seal.

  3. The parameters (without the access key!) and seal are sent to our server (activation of the payment window).

  4. The web server confirms points 1 and 2; the access key taken from the Configuration.

  5. The calculated hash value is compared with the transmitted seal. When these match, the transmitted data has not been manipulated.

  6. If just one character in the parameters has been changed, the hash values will not match. The server then rejects the query. As the access key is not known to the attacker, he is unable to generate the correct hash.

The following PHP code demonstrates the creation of a seal on the partner's web server:

<?php
// the parameters to be encrypted
  $sealedParams = 'project=Projekt&title=Artikel&amount=100';

// unencrypted paramters
  $unsealedParams = '&account=Webmaster&bgcolor=000000';

// the secret access key
  $accessKey = '0123456789abcdef0123456789abcdef';

// Creating the seal
  $seal = md5($sealedParams . $accessKey);     
 
// URL generation and output
  $url = 
    'https://{Pay-Domain}.../?' . 
    $sealedParams . 
    '&seal=' . $seal .
    $unsealedParams;

  echo '<a href="' . $url . '"> Make Payment Now </a>';
?>
return to the top