Payment processing

Payment via the payment provider

Introduction:

You determine the offer and the price for your products / services. The client selects a product in your iframe. To initiate the payment process , call up a lightbox with the onOffice payment dialog . Here, onOffice asks the user to confirm the order.

The possible payment methods are credit card and SEPA direct debit. Several credit cards or bank details can be stored per account. The client chooses the appropriate payment method when purchasing. We work together with the payment provider Mangopay for the transfer of payments. When adding a provider, you can let us know if you want to restrict the possible payment methods for your service (e.g. client should only be able to pay by credit card).

Each Marketplace partner concludes a separate contract with Mangopay and receives an account there, which we set up for you. The income can then be transferred to your own account via a pay-out . In your transaction overview under the menu item Marketplace >> Provider account you can view all transactions made.

Sandbox and production mode:

There are basically 2 different modes in which the Marketplace runs. Sandbox mode is used to test your store in the development phase and all transactions are carried out without real money using test credit cards.

In production mode , all transactions are carried out with real money. Once your store has been fully programmed and tested, your store can be converted to production mode .

Let us know if you would like us to convert your store. We at onOffice will then test the interfaces of your store to onOffice enterprise and exchange your wallet ID.

In order to be able to continue testing later extensions of your store, we can set up a second test provider for test purposes, which runs in sandbox mode. Please contact us if you require a test provider in sandbox mode. Please provide us with the activation and service URL as well as the MangoPay walletid of your test service. All other information is the same as for your real provider.

At the top right of the menu bar in enterprise, the status is displayed as“Sandbox” or“Production” in your provider customer. If it does not say “Sandbox” or “Production”, then your provider is not (correctly) linked. In this case, please contact us. Under no circumstances should you create any accounts.

Test credit cards:

In order to be able to test the payment processing, Mangopay offers Test cards to simulate transactions. Due to the changeover to 3DSV2-Secure, only the 2 3DSV2 test cards with “frictionless flow” and “challenge flow” can be used. The “frictionless flow” is more suitable for testing, as no 3DSV2 input should usually be necessary here, but no large amounts can be booked.

I.e. Test cards that do not have a 3DSV2 query will therefore not work. The functioning test cards are currently 4970105191923460 and 4970105181854329.

Alternatively, you can use the cards under “liability shift” with the password stated on the page, although a 3DSV2 security check is always carried out.

FR7630004000031234567890143 works for SEPA transactions. If the test credit cards do not work, this can be used as an alternative.

KYC documents for MangoPay:

The EU Anti-Money Laundering Directive requires a legitimation check in the form of KYC documents (Know your customer), therefore we ask you to provide us with the following documents:

IDENTITY PROOF -> Passport, identity card or driver’s license
REGISTRATION PROOF -> Extract from the commercial register
ARTICLES OF ASSOCIATION -> Social contract
SHAREHOLDER DECLARATION -> List of shareholders (https://www.mangopay.com/terms/shareholder-declaration/Shareholder_Declaration-EN.pdf)

Transaction list: Pay out and cancel transactions

Under the menu item Marketplace >> Provider account you can view all transactions that your clients have made with you.

Filter bar and icons:

Filter bar: In the upper area, you can use the filter bar to control the transactions displayed in the transaction list. You can filter according to date ranges, the transaction ID or other criteria in “Additional filter 1:”. The booking date or the value date can be selected as the date reference. SEPA transactions, for example, can take several days to complete.
Cancel booking: Transactions can be canceled in your transaction overview via the icon for “Cancel booking”. The repayment of the transfer is triggered via the Mangopay API. The canceled transaction is displayed in the transaction overview as a transaction with a negative amount. The buyer will receive an e-mail about the transaction being canceled. No transactions older than 11 months can be canceled. Cancellation is only possible if the status of the transaction is set to successful. This means that transactions with payment type SEPA that are “in process” cannot be canceled. A reversal is also possible via API with the API call Cancel transaction is possible. In the event that the wallet is not sufficiently covered, a response is sent: “This Mangopay account is not sufficiently funded. Cancellation could not be carried out.” Therefore, we recommend leaving a small amount of money in the accounts in case there are cancellations. Otherwise there may be problems if you cancel an account that is not covered. Please note that currently only the entire amount can be transferred during payout.
Cancel subscriptions: You can cancel subscriptionsvia the hourglass icon.
Generate post-payment link: You can use the euro icon to generate a post-payment link and send it to your clients.
Details of the transaction: You can view further details on the transaction via the magnifying glass icon. Here you will find other important information such as the payment method (credit card or bank account), the buyer’s billing address and detailed information about the order.

Columns:

Booking day: Date of purchase.
Value date: Date of the value date.
Transaction ID: Transaction ID of the purchase.
Reference ID: Your clients can use the “Reference ID” field to assign a Mangopay debit to their bank account to a paid Marketplace service. The reference ID is communicated to the bank as a reference number and appears on the account statement. The reference IDs are unique for each customer.
Mangopay account ID:
Status: The Status column shows the status of the transaction. Possible values are: successful, failed or in progress. The status “in process” is always and only set for the SEPA payment type. In this case, the payment provider has requested the direct debit from the bank. The money is only collected from the client after a few days. On the following day, the status is changed to successful if the payment was successful. In principle, you can treat the status “in preparation” in the same way as “successful”. If a payment fails, you will be informed by e-mail and the payment will be set to failed. The money must then be requested by means of an additional payment link .
customer: onOffice customer who made the purchase. A customer can have many users.
Buyer: onOffice user who made the purchase. A user belongs to a customer.
Price: Price of the purchased product.

Account balance, payout and data export:

Account balance: The current balance of your Mangopay wallet is displayed here.
Payout: You can transfer the entire amount of your Mangopay account to the bank account you have provided via “Execute payout” . A security prompt follows: “Would you like to arrange a payout? The full amount on your Mangopay account (XXX,XX€ ) will be transferred to the account with the IBAN ***0147. Attention. Cancellations are only possible again once the account has sufficient funds.” The purpose of the transfer is “Marketplace”. In the transaction list, the payout is displayed as a transaction of the type “Payout”. Payment of partial amounts is currently not possible.
CSV export: The “Current month” and “Last month” links under“CSV export” can be used to download the transactions for the current and last month as a CSV file. The current, filtered selection in the transaction list is exported via “Filtered list”.

Process of a transaction:

Using the example of floor plan optimization, the process of a transaction is as follows (in italics):

The client selects the product in your iframe.
Example The client opts for floor plan type B at a price of €14.90.
The provider calls up the onOffice payment dialog and transmits the name, price and quantity for the selected product.
Example The floor plan provider calls up the onOffice payment dialog and transmits the name for the product selected by the client (e.g. floor plan type B), the price (e.g. 14.95€) and the quantity.

Lightbox Marketplace order
The client confirms the purchase. For some purchases, the client may be redirected to a 3D Secure page of their bank/credit card company, where they must authenticate themselves with a security code. OnOffice then initiates the payment process with the payment provider. He collects the amount from the client and transfers it to your account.
Example The client confirms the purchase of floor plan type B at a price of €14.95. The amount will be transferred to your account.
onOffice sends information about whether the purchase has been confirmed or whether there was a problem. If the purchase was successful, the client receives an order confirmation by e-mail.

Marketplace in other countries / VAT:

The Marketplace will gradually be made available in other countries besides Germany, Switzerland and Austria in the future. The Marketplace has also recently been launched in Italy, Spain, Slovenia, Croatia and Luxembourg; in the initial phase there may still be a few suppliers available for the new countries.

Whether and which VAT must be paid depends on the buyer’s billing address in the Marketplace account and the supplier’s country.

VAT is taken into account in the order pop-up as follows:

The billing address is in the same country as the provider and a VAT ID is entered: VAT of the country will be charged.
The billing address is in the same country as the provider and no VAT ID is entered: VAT of the country will be charged.
Billing address is different from the country of the provider and no VAT ID is entered: VAT of the provider country will be charged.
Billing address is different from the country of the provider and a VAT ID is entered: No VAT will be charged.

The currently valid VAT rates for the countries in which the Marketplace is available are as follows:

Germany 19%
Italy 22%
Croatia 25%
Luxembourg 17%
Austria 20%
Slovenia 22%
Spain 21%

Note: Swiss clients generally do not pay VAT.

Further information on the VAT ID can be found on Wikipedia.

Structure of the payment processing link

After the client has placed an order from the provider’s iframe, the lightbox for payment opens.

The service called up in the iframe must transfer the data to the parent window as a JSON string via postMessage. The JSON string must be signed with the provider’s secret so that the request can be authenticated.

The JSON should have the following structure:

{
  "callbackurl": "https://www.anbietershop.de/HandleonOfficeOrderResponse.php",
  "parametercacheid": "0e81f10f-6de8-4edc-cdcf-de96cf61624c",
  "products": [
    {
      "name": "onOffice Sample 1",
      "price": "5.99",
      "quantity": "3",
      "circleofusers": "customer"
    }
  ],
  "timestamp": 1565689180,
  "totalprice": "26.47",
  "signature": "649ee3dfbfb53187a9b2b66fafb658df24ca037c6de473fe9bcee2e327289dd5"
}

Please note: Currently, only one product can be offered per order. Please note: SEPA payments are handled differently and have their own “inprocess” status. More about this in the explanation of the “status” parameter.

Explanation of the parameters

}, “callbackurl”: This URL is called after a payment and returns several parameters per querystring (plus possibly individual parameters):
- “transactionid”: A unique ID of the specific transaction. This is to be stored by you for subsequent processing purposes as well as for traceability purposes
- “referenceid” : This reference ID appears on the bank transfer slip as the customer reference number so that the customer can allocate the transaction.
- { “status”: Returns either “success”, “inprocess” or “error”. The status “inprocess” is only used for the payment type SEPA direct debit, because there the processing of the transaction can take several days. I.e. “inprocess” is always a SEPA transaction. In this case, the payment provider has requested the debit from the bank. The money is collected from the customer only after a few days. On the following day, the status is then changed to “success” if the payment has worked out. In principle, the “inprocess” status can be treated in the same way as the “success” status. If a payment fails, you will be notified by mail and the payment will be set to failed. The money must then be demanded by subsequent payment link .
- “errorCodes”: Returns an error code if an “error” was returned. (Error codes and descriptions see Error codes.)
- “message”: Returns the description of the error code if an “error” was returned.
- “timestamp”
- “signature”
Other individual parameters (e.g. product ID) that might be necessary for your processing can be freely defined by you. The callback URL should also be checked for the signature.
“parametercacheid: Is passed to the provider as a querystring parameter during service and must be returned here. The parameter contains internal information that is stored in the parameter cache.
{ “products”: Here the products selected by the user must be listed with “name”, “price” and “quantity”. “circleofusers” is optional and determines the circle of users for which the purchase was made. Possible values: Client (customer), office group (group), user (user). It is important that the price is always supplied with a dot “.” as a decimal separator . Also, no other separators such as thousands separators may be used, and the price is supplied as the net price . In addition, all prices should always be quoted with two decimal places . Please note: Currently, only one product can be offered per order.
}, “timestamp”: Here a timestamp is to be generated, which flows into the signature and thus makes it unique.
“totalprice”: This is the total price over all products. (The same rules apply here as for product prices)
“signature”: This must be formed over the JSON string so that the validity can be validated. (see explanation of the signature)

In the code samples you can find a sample store with the implementation of the signature generation. Please note that the demo store does not validate the URL or signature, so this must be implemented by you.

Error codes

If an error occurs during the order and an “error” is returned as “status”, the following error codes may appear as “errorCodes”.

Possible errors:

1000 An unknown error has occurred
1001 Json-string could not be read
1002 Signature was not correct

1011 A price did not have the correct formatting. Expected is a price with two decimal places with decimal point (e.g. 15.23)
1012 Total price is not correct. The total price must match the price in the product or monthly subscription payment.
1013 Data structure not correct. Either exactly one product record or exactly one subscription record must be passed.

1021 Parameter timestamp is missing.
1022 Parameter signature is missing.
1023 Parametercacheid is missing.

1031 Transaction has already been executed (for subsequent payments).
1032 The logged in user does not match the submitted userId.
1033 The customer does not have an active account.

1101 MANGOPAY error: Customer does not have MANGOPAY Wallet.
1102 MANGOPAY error: Customer has not set a payment method.
1103 MANGOPAY error: Provider does not have a MANGOPAY wallet.
1104 MANGOPAY error: Payment can not be made because of 3D Secure.
1105 MANGOPAY error: Deposit to MANGOPAY wallet not possible.
1106 MANGOPAY error: Transfer to MANGOPAY wallet not possible. Not enough money on the customer’s MANGOPAY wallet.
1107 Unknown error during payment process at MANGOPAY.

8505 The limit of ten payments per day per credit card was exceeded.

In all cases, no payment has been made, so any errors should be handled by you as the provider.

Explanation of the JSON string signature

The method for signature calculation can be found in CreateProductJsonOrderwithSignature.php of the demo store website. The process of signature calculation happens as follows:

Call the sign function to sign.
Adding a timestamp.
Sorting the parameters from A-Z: First, all entries are sorted according to the parameter name.
Creating the signature:
- sha256 is used as an algorithm.
- The provider’s secret is used as the key.
- The JSON data is converted to an array via json_decode($jsonString, true) . This is then assembled into a string using http_build_query($jsonArray, '', '&', PHP_QUERY_RFC3986); . This string is then signed via hash_hmac(‘sha256’, $jsonQueryBuildString, $AnbieterSecret); .
Finally, the obtained signature is appended in the JSON array and then the array is converted back to a JSON string via json_encode($jsonArraywithSignature, JSON_UNESCAPED_UNICODE|JSON_UNESCAPED_LINE_TERMINATORS) .

Frequent problems with signature calculation:

The query string to be signed was calculated according to an incorrect RFC. It should be calculated correctly according to RFC 3986.
The signature was calculated as a base64-encoded binary string, but must be calculated as a hexadecimal value.

Example of signature calculation with test data:

// Call the function sign($jsonData, $secret) in CreateProductJsonOrderwithSignature.php with the parameters JSON-Data and
// and Secret:
$jsonData = '{"totalprice": "17.97", "callbackurl": "https://www.anbietershop.de/HandleonOfficeOrderResponse.php", "parametercacheid": "0e81f10f-6de8-4edc-cdcf-de96cf61624c", "products":[{"quantity": "3", "circleofusers": "customer", "price": "5.99", "name":"onOffice Sample 1"}]}'
$secret = 'myTestSecret'

// Add timestamp (here 1565689180);
$jsonDecodedContent = json_decode($jsonData, true);
$jsonDecodedContent['timestamp'] = time();

// Sorted array after passing $contentSorted = sortParameters($jsonDecodedContent):
[
"callbackurl" => "https://www.anbietershop.de/HandleonOfficeOrderResponse.php",
"parametercacheid" => "0e81f10f-6de8-4edc-cdcf-de96cf61624c",
"products" => [
[
"circleofusers" => "customer",
"name" => "onOffice Sample 1",
"price" => "5.99",
"quantity" => "3"
]
],
"timestamp" => 1565689180,
"totalprice" => "17.97"
]

// The string to be signed looks like this after calling http_build_query($jsonArray, '', '&', PHP_QUERY_RFC3986)
// then looks like this:
callbackurl=https://www.anbietershop.de/HandleonOfficeOrderResponse.php¶metercacheid=0e81f10f-6de8-4edc-cdcf-de96cf61624c&products[0][circleofusers]=customer&products[0][name]=onOffice Sample 1&products[0][price]=5.99&products[0][quantity]=3×tamp=1565689180&totalprice=17.97

// The secret "myTestSecret" is used to generate the following signature via $jsonSignature = hash_hmac('sha256', $jsonQueryContent, $secret)
//:
49b818db62d1b86640ea34f4525e64809fa44d5e0b90ad719aadd5425f66c9ba

Subscriptions

The Marketplace can also offer subscriptions for products or services that are billed monthly. The subscription starts immediately after purchase. The first installment for the subscription will then also be billed. The subscription ID and transaction ID are transferred.

The JSON transfer parameter for a subscription is described below.
There is a JSON string for subscriptions and one for products (see above).
It is only possible to transfer either a product or a subscription per call.

{
  "callbackurl": "https://www.providershop.de/HandleOrderResponse.php",
  "parametercacheid": "0e81f10f-6de8-4edc-cdcf-de96cf61624c",
  "abo": {
    "monthlycosts": "25.70",
    "monthlyservicedescription": "5 3D-Rundgänge",
    "durationinmonth": "6",
    "noticeperiod": "bis 3 Monate vor Vertragsende",
    "automaticrenewal": "12 Monate",
    "circleofusers": "customer"
  },
  "timestamp": 1565689180,
  "signature": "649ee3dfbfb53187a9b2b66fafb658df24ca037c6de473fe"
}

“callbackurl”: This URL is called up after a payment and returns several parameters per query string (plus any individual parameters):
- “transactionid” : A unique ID of the specific transaction. With a subscription, each monthly debit is a transaction. This should be stored by you for later processing purposes and for traceability
- “aboid” : A unique ID of the subscription. This should be stored by you for later processing purposes and for traceability
- “referenceid” : This reference ID appears on the bank transfer form as the client reference number so that the client can assign the transaction.
- “status”: Returns either “success”, “inprocess” or “error”. The “inprocess” status is only used for the SEPA direct debit payment type, as it can take several days to process the transaction. This means that “inprocess” is always a SEPA transaction.
- “message: Returns an error text if an “error” was returned. (See below for error texts)
- “timestamp”
- “signature”
“parametercacheid”: Is transferred to the provider as a query string parameter for the service and must be returned here. The parameter contains internal information that is saved in the parameter cache.
“abo”:
- “monthlycosts”: monthly costs of the subscription
- “monthlyservicedescription”: Description of the product for which the subscription is taken out
- “durationinmonth”: Term in months
- “noticeperiod”: Notice period
- “automaticrenewal”: Period of automatic renewal
- “circleofusers”: User group for which the purchase was made. Possible values: Mandant (customer), Bürogruppe (group), Benutzer (user)
“timestamp”: A timestamp is to be generated here, which flows into the signature and thus makes it unique
“signature: This must be formed via the JSON string so that the validity can be validated. (see explanation of the signature)

All parameters are mandatory parameters.
All subscription parameters, except the prices, are only used for the output.

“circleofusers” specifies the user group for which the purchase was made (→ see Orders for multiple users).

The error texts and the signing of the JSON string are the same as for the one-time purchase of a product.

Note if subscription payment fails:

It may happen that the monthly subscription amount cannot be collected, e.g. because the clients’s account is not covered, the account has been closed or the amount could not be collected for other reasons.

In this case, you and the client will receive an e-mail from us stating that the subscription amount could not be collected. Seven days later, a second and third attempt is made to collect the amount again. You and the client will be informed by e-mail.

After 3 failed attempts to collect the amount, the collection of the subscription amount for this month has failed and you will receive an e-mail about this.

This means that you are then responsible for invoicing the client for the missing amount. You can do this conveniently via the post-payment link , for example.

3D-Secure: Purchases sometimes require client confirmation by 3D-Secure (3DS2). As a rule, no further queries are made by 3DV2-Secure for subsequent recurring payments after a subscription has been taken out. When making the first payment, the client gives permission for future payments of the same amount to be made without 3DS2.

In rare cases where a direct debit nevertheless fails due to 3DS2, the amount due will be collected via a subsequent payment link . In the event of such a failed transaction, a post-payment link will be sent to the buyer by e-mail. You as the provider will receive an e-mail for information. In this case, no further attempts will be made to debit the account.

The subscription will remain active as long as you do not cancel it, so that the subscription amount will be collected again the following month.

Cancel subscriptions:

Subscriptions do not expire automatically. If a subscription is to be terminated, you can cancel the subscription via the GUI in your onOffice provider customer.

To do this, go to the menu item“Marketplace >> Provider account“. Clicking on the “hourglass” icon opens a view in which you can set the cancellation date for the subscription. No further debits will be made after this date.

API call to end a subscription:

Subscriptions do not expire automatically. If you wish to cancel a subscription, please let us know via API. The “cancelationDate” is transferred in the API call for canceling a subscription . No more direct debits will be made from this date (incl.).

{
  "actionid": "urn:onoffice-de-ns:smart:2.5:smartml:action:do",
  "resourceid": "",
  "identifier": "",
  "resourcetype": "marketplaceCancelAbo",
  "parameters": {
    "aboid": "5",
    "cancelationDate": "2019-10-05"
  }
}

Invoicing:

onOffice does not issue an invoice to clients in the Marketplace at the time of purchase, i.e. it is your responsibility to issue an invoice to the client. You are obliged to issue an invoice to the client, as the purchase of your services or products constitutes a legally binding transaction.

API call-off “Data of the invoice recipient”

To automate invoicing, you can read out the invoice recipient’s data using the API call“Invoice recipient data“.

{
  "actionid": "urn:onoffice-de-ns:smart:2.5:smartml:action:get",
  "resourceid": "",
  "identifier": "",
  "resourcetype": "getMarketplaceInvoiceRecipient",
  "parameters": {
    "transactionid": "12345678",
    "userid": "123"
  }
}

Necessary parameters are “transactionid” and “userid”
Country is returned as an ISO 3166-1 alpha-3 value when the API is called.
API error messages:
- 184: User id is not existing or inactive (INFO: User id in the order is not the same as the transaction buying user id)
- 188: The user data could not be found
- 189: The transaction could not be found
- 190: The time to call the transaction has expired

All API calls used in the Marketplace are also described in the official API documentation .

Automated invoicing – queries from the invoice recipient

Previously, only customer IDs and API keys were stored. There can be X invoice recipients behind a customer ID.

Any number of users can work in an onOffice customer version (over 1000 users in the largest customer version). If the brokers are employed as franchisees by a large network but still work independently, they have their own group or user account with the payment provider. The invoice must then be issued to the respective agent accordingly.

As a provider, you can automate invoicing or carry it out manually. onOffice sends an e-mail with the data of the respective invoice recipient for each booking. In the case of automation, the invoice recipient’s data can be requested from onOffice via the API call“Invoice recipient data“.

In the payment dialog, the client confirms his purchase. onOffice sends the provider the information that the purchase has been successfully completed. This event serves as a trigger for querying the invoice recipient.
The invoice recipient is read out via the API call “Invoice recipient data” ..
…and booked in your system for invoicing.

Commission

Once the payment process has been initiated with the payment provider, the amount is debited from the client ‘s account. Of this, one provision goes to onOffice, the remaining amount is transferred to the provider’s account. You can have the amount paid out via a payout in your provider version (Production).

All fees for the payment provider are deducted from the commission. The net price of the product serves as the basis for the commission calculation.

The Mangopay service is therefore free of charge for you as a provider.

Procedure for payment problems and failed transactions

General:

If there is a problem with a payment (SEPA or credit card) or if a transaction has failed, we ask the client in the first step to check whether there could be a reason on their side (e.g. account not covered, limit on the card) and then to try the transaction again.

We then advise the client to contact you as the provider, stating the transaction number, so that you can check whether there is a problem on your side. If an error occurs during the order, an error code will be returned to you, which may indicate the possible cause.

Once the problem has been resolved, you can ask the client to carry out the transaction again or, if necessary, send a post-payment link to the client by email. Click on the link in the e-mail to open the order pop-up. The client can then pay the amount directly there if they still wish to carry out the transaction.

If problems persist, we advise the client to contact onOffice support, where we can then check the transaction.

One-off payments with SEPA:

For purchases via a bank account with a SEPA mandate, it may take a few working days for the transfer to be completed. Until then, the transaction will be marked as “in progress” in the transaction list for your clients. As a rule, the booked service should be available immediately after purchase.

If the transfer fails for any reason, we will inform you as the provider by e-mail. You can then send your client a post-payment link by e-mail to complete the transaction. The order pop-up opens via the link and the client can subsequently complete the purchase.

Disputes

In rare cases, disputes may arise with purchases, i.e. a client may demand payment back from the bank. The money is then first debited from onOffice. You will receive an e-mail from us asking you to cancel the corresponding transaction in your provider customer. The buyer will also be informed of this by e-mail.

You can trigger this in the provider customer under “Marketplace >> Vendor account” via the “Back arrow” icon “Cancel booking” for the individual transactions. If this has not happened within a certain period of time, onOffice would carry out the cancellation for you in the provider customer.

If a dispute has been registered for a transaction, the transaction receives the status “Clarification required” in the transaction list. Note: There are also disputes that cannot be canceled because they may not be contestable.

Settling subsequent costs

It may be the case that the scope of the order changes due to subsequent communication with the client or that a direct debit fails although the client can already use your service (e.g. in the case of SEPA payments or ongoing subscription payments). The costs must then be billed retrospectively.

Using the example of floor plan optimization, this could look as follows:

The client orders the optimization of a floor plan at a price of €14.95. He does not observe the provider’s limitation and orders the optimization with too large an area and number of rooms (e.g. 340m², 18 rooms). The floor plan provider contacts him and refers to the amount to be paid for this, which the client agrees to. A sum X must be recalculated.

The procedure is as follows:

The floor plan provider sends the client an e-mail containing a link that triggers the payment process.
This link is composed as described in the following section “Structure of the link for subsequent billing”.
The client must be logged into onOffice with their user when accessing the link. If this is not the case, the user is prompted to log in.
The payment dialog then opens.
If the client confirms the dialog, the costs are transferred.

The provider sends the client an e-mail with the signed link to the payment dialog.
The client confirms the payment and the provider is informed about the confirmation of the payment.

Sending additional payments / generator for the additional payment link

In your provider customer, you have the option of generating a post-payment link that you can send to your client. The post-payment link takes the client to the lightbox for the purchase, where they confirm the post-payment. To do this, use the euro icon for each transaction in your vendor account under “Marketplace >> Vendor account”.

A lightbox will open in which you can enter the name of the additional service and the price. The subsequent payment link is then generated. You can send this directly to your client via “Send post-payment link by e-mail”. A standard mail template with the sender “noreply@onoffice.de” is used for this.

Or you can send the generated link to your client yourself using your own template.

Icon for additional payment link

Template for subsequent settlement

This is always a subsequent payment for a purchase already made via the Marketplace. This can be a one-off purchase or a subscription. You define the e-mail to the client for subsequent billing. For example, it could be structured as shown in the illustration. You can download this template here as HTML for your use.

Back payments

After clicking on “Order additional service here”, the lightbox for the payment opens.

Checking the validity of the PSP account:
We use the user ID to check whether the user has an active Mangopay account at the time of the call.

Check signature and active session:
When the link is executed, we check whether the link is correctly signed.

In addition, the link can only be called up if the user is logged into the specified customer with their account (from which the original order was placed). If the user is not logged in, a login screen opens. After successfully logging in, the link can then be accessed. The recipient must call up the link in the same browser in which the onOffice session is running.

This post is also available in: German