The interface is currently implemented with the help of two alternative technologies.

http://webservice-url/?action=func-name&param-name=param-value&param-name=param-value&...

error=0
result-name=result-value
result-name=result-value
...

error=error-code
errormessage=error-message

http://webservice-url/?...&param[index]=value&param.property=value

result[index]=value
result.property=value

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope
  soap-env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:dbt="http://webservices.micropayment.de/public/debit/version1.0"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soap-env:Body>
    <dbt:func-name>
      <param xsi:type="dbt:Dbtfunc-nameRequestTyp">
        <param-name xsi:type="param-type">param-value</param-name>
        <param-name xsi:type="param-type">param-value</param-name>
        ...
      </param>
    </dbt:func-name>
  </soap-env:Body>
</soap-env:Envelope>

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope
  soap-env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:dbt="http://webservices.micropayment.de/public/debit/version1.0"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soap-env:Body>
    <dbt:func-nameResponse>
      <return xsi:type="dbt:Dbtfunc-nameResponseTyp">
        <result-name xsi:type="result-type">result-value</result-name>
        <result-name xsi:type="result-type">result-value</result-name>
        ...
      </return>
    </dbt:func-nameResponse>
  </soap-env:Body>
</soap-env:Envelope>

<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope
  soap-env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"
  <soap-env:Body>
    <soap-env:Fault>
      <faultcode>error-code</faultcode>
      <faultstring>error-message</faultstring>
      <faultactor></faultactor>
      <detail></detail>
    </soap-env:Fault>
  </soap-env:Body>
</soap-env:Envelope>

Each query is sent to a defined service URL with the required accessKey parameter for the identification of the partner submitting the query. This access key is generated automatically when the partner registers with the MicroPayment system. The key can be viewed in the ControlCenter. Alternatively, all functions are responsive to the testMode parameter. With this parameter you can activate the integrated test environment.

If a function fails, the error that resulted is described by the error and errorMessage responses. error contains a numerical code that can be analyzed by the program. errorMessage, by contrast, contains a more detailed description of the error in plain text. It should also be protocolled in the event of an error.

The API is able to send various events to an interface of the project operator. For this to occur, the URL of the interface must be entered into the project configuration. All notifications contain the testMode parameter. This parameter indicates if the notification was triggered by the test environment.

If a error is received when the notification URL is queried, an automatic e-mail is sent to the operator with the parameters of this failed query.

All functions are ready to receive the optional testMode parameter. When this parameter is used, the data are generated and queried in a separate test environment (the so-called "sandbox"). None of the payment sessions saved here are ever carried out. With special functions several external events can be simulated in the test environment, however.

The test environment allows you to test all of the transaction steps during and after the integration of the API in a simulated environment, and to even implement automated test cases (unit tests).

In order to simplify error management, the error codes for the return message error are subdivided in four different classes, each with their own number group.

The Appendix contains a summary of all error codes, causes, and tips for repair.

This function deletes all customers and sessions in the test environment. With the help of this function, conflicts regarding the customerId and sessionId can be avoided, among other things, in connection with automatic unittests.

An overview of all parameters and responses is provided by the Quick Reference Quide.

A customer must be added prior to each payment transaction. For identification, a unique customer number, user name, or e-mail address can be sent for customerId; otherwise a unique ID will be created and returned by the API. The function will fail if an account already exists for the customerId value.

	Caution
	If multiple projects are being run for which the customer must register separately, various prefixes should be added before the customerId value. For example: "prj1:john@doe.com".

With the associative freeParams list, you can add as much additional data as you want to the customer data using free parameters. This data can be later retrieved with customerGet or changed/amended with customerSet. Integration with the API is thus possible in principle even when the customer does not have his own database, as all customer data - such emails, passwords, and blocked status - can be saved as free parameters.

An overview of all parameters and responses is provided by the Quick Reference Quide.

Free parameters can be added to a customer data set at any time, or existing parameters can be changed. In the process, only values that are contained in the freeParams parameter are created or overwritten; existing values remain unchanged. To delete a value, simply send an empty string ("").

An overview of all parameters and responses is provided by the Quick Reference Quide.

This function retrieves all free parameters that have been sent to the customer data set with customerCreate or customerSet.

An overview of all parameters and responses is provided by the Quick Reference Quide.

After a customer has been added, a bank account must be added as well before a payment can be made. If this bank account information needs to be changed at any point in the future, the new bank account information can be sent with this function. The parameter customerId is used in this connection to identify the customer. The function checks the plausibility of the account number and bank ID in accordance with the specifications of the German Central Bank and, if necessary, fails. If the query is successful the name of the bank associated with the bank ID will the returned (only in the case of a German bank).

An overview of all parameters and responses is provided by the Quick Reference Quide.

The stored bank data for a customer can be retrieved with this function. This function be used, for example, in order to allow the customer to edit the data.

An overview of all parameters and responses is provided by the Quick Reference Quide.

After a customer and associated bank account info has been saved, a new payment session can be created. The sessionId parameter must be unique and will be generated and returned if necessary - similar to the customerId parameter in the customerCreate function. For this parameter is often best to provide the user's current session number in order to prevent double bookings.

The project and projectCampaign parameters determine which project and campaign the payment should be applied to. The account and webmasterCampaign parameters are required if the project is being run with a third-party webmaster.

	Important
	The function will fail if an invalid or blocked campaign has been entered in the projectCampaign parameter. However, if the webmasterCampaign entry is invalid, the parameter will just be ignored.

The product name, payment amount (in cents), and currency are defined with amount, currency, and title. If these parameters are omitted, the standard values from the project settings will be used. The reason for payment is indicated under payText and is generated based on the project name and title parameter. With the sessionGet function all transferred or generated values can be retrieved. This is useful, for example, in order to display information to the customer.

	Important
	If the configuration has been set such that only standard values should be used, the parameters amount and title are ignored.

Similar to the customerCreate function, free parameters can be added to the payment session and later retrieved with the sessionGet function. The separate ip parameter is stored with the time stamp in order to address instances of fraud. This parameter should contain the IP address of the user who executed the payment.

This function typically returns the status "INIT". If an unconfirmed session has been found for a customer, however, the session will be overwritten with the values in the query and the status "REINIT" is returned.

If a query with the sessionCreate function is successful, the notification sessionStatus will be triggered.

	Caution
	The sessionStatus notification takes place right away, even before the response is returned.

An overview of all parameters and responses is provided by the Quick Reference Quide.

This function lets you determine the actual status of a session, as well as retrieve all data from the parameters in the sessionCreate function. The following responses for status are possible:

In the case of a "FAILED" or "REVERSED" status, a detailed explanation of the cause is provided in plain text under statusDetail.

In addition, all data corresponding to the parameters from the sessionCreate function are returned. For optional parameters the presettings or specifications from the configuration will be returned.

An overview of all parameters and responses is provided by the Quick Reference Quide.

Saved payment sessions must be confirmed with this function. The session should be queried with this function immediately after debit order confirmation is received from the customer, or even after the delivery of the purchased article (i.e. after the completed download of a document).

If a query with the sessionApprove function is successful, the notification sessionStatus will be triggered.

	Caution
	The sessionStatus notification takes place right away, even before the response is returned.

An overview of all parameters and responses is provided by the Quick Reference Quide.

With the aid of this function, all open and all completed session for a customer can be retrieved. The response consists of a numerically indexed list of associated sessionIDs.

An overview of all parameters and responses is provided by the Quick Reference Quide.

All confirmed payments are compiled and submitted to the bank for debiting. The subsequent incoming payment typically triggers the status change "CHARGED" and a corresponding sessionStatus notification. The function allows the simulation of this incoming payment in the test environment.

An overview of all parameters and responses is provided by the Quick Reference Quide.

This function simulates the reversal of a payment in the test mode. In reality, for example, the reversal of a payment can be triggered if the account holder rejects the payment, or if there are insufficient funds in the bank account. sessionStatus is used to provide notification to the target system.

An overview of all parameters and responses is provided by the Quick Reference Quide.

Every status change in a payment session (including its initial creation) leads to a notification with this function. For example, when a payment amount is confirmed, debited, or cancelled. The sessionId, current status, and all free parameters are also sent.

As a result new or changed freeParams can be returned and added to the session.

An overview of all parameters and responses is provided by the Quick Reference Quide.