Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Availability by country/currency

Payment Type












Functional limitations and additional information

Right now there are certain limitations for BS PAYONE Secure Invoice that need to be taken into account during the implementation. All information that is relevant for the merchant is summarized here.

UI Text Box
  • Currently no support for increasing receivables with a debit request.
  • Processing only possible for EUR currency for Switzerland.
  • Currently no support for refunds after start of encashment.
  • To set up your merchant account for secure invoice, we need to configure a new dedicated payment portal for this payment method. Please make sure, that you send the dedicated portalid and key within your requests for clearingtype REC with subtype POV.
  • shipping address and invoice address must be same for a payment guarantee to be granted


In some shop systems, there is no dedicated switch for B2B/B2C transactions. To solve this, a transaction is flagged as B2B when the parameter company is filled. There is no further check, if the company name is correct.

Request "preauthorization"

During the preauthorization and authorization a risk check for the customer is performed. Depending on the result the customer qualifies or disqualifies from using this payment method. When the risk of payment default is deemed too high the transaction can’t be insured and the customer is denied, yielding an error message and the status “ERROR”.

Generally, the more customer data you send, the better the risk check can decide to give an insurance or not. Nonetheless, there following table contains flags, if a parameter is optional or not.

If the preauthorization/authorization is successful the response will contain the status “APPROVED”.

Using the Preauthorization request does NOT finalize the claim. In order to start the dunning process the transactions need to be captured first. See: capture

Please bear in mind, that a preauthorization is valid for 28 days. You need to make sure, that you capture this preauthorization in this period. Otherwise, if you know that you won’t capture the amount, please send a cancel (capture with amount=0), to free the reserved guarantee.

Request "capture"

If the transaction was initialized with a preauthorization request, you have to capture the transaction after fulfillment. The dunning process will not be started before capturing the transaction.

Since during the pilot phase not all scenarios involving multi partial capture have been tested it is recommended to only capture the full amount of the preauthorized transaction.

Request "authorization"

The authorization request simply combines both the prauthorization and the capture steps.

Remarks to API parameters

Clearingtype / Clearingsubtype



Excerpt Include
clearingtype - definition
clearingtype - definition

fixed value "rec"

Excerpt Include
clearingsubtype - definition
clearingsubtype - definition

fixed value "POV"

Excerpt Include
company - definition
company - definition

If the company name is set the transaction will be considered B2B. There is no further check, if the company name is

Excerpt Include
businessrelation - definition
businessrelation - definition

Not mandatory by now, but strongly recommended to be used.

Please use parameter "businessrelation" to specify whether the customer is a person or a company.

If this parameter is not used the existence of value for parameter "company" is used to identify b2b-payments.


Excerpt Include
birthday - definition
birthday - definition

Mandatory for b2c transactions.

Excerpt Include
email - definition
email - definition
Mandatory for POV.

Special test cases

See: Secure purchase on invoice

Sequence diagram 

See: Secure invoice

Table of Contents