Always one step ahead
Your business is growing and no one knows what services you will need in the future.
All the more important that you have a partner who will always give everything to ensure that you are perfectly positioned.
| Development of a debtor portal for a collection company |
| Product Branch |
| Fulfilment, collection |
| Principal |
| www.ideal-fullservice.de |
| Project partner |
| none |
| Abstract |
| CommDoo has built an end customer portal for a large provider of fulfillment and collection services. |
| Challenge: Simplifying payment processes in debt collection. |
| For debt collection companies, the allocation of payments to debtors always involves a lot of manual work: Not every payment can be assigned automatically and the complicated search for the right debtor can take a lot of time; in the worst case this is not even possible and money has to be kept as foreign money or transferred back. The provider already provided his customers with a contact form on the Internet. This contact form was to be extended by the possibility that debtors can directly trigger payments via the contact form, which are then automatically booked by the system. |
| Implementation |
| The obvious solution was for the customer to click on a link on the contact form and then be redirected to CommDoo to make a payment via PayPal, giropay or cash. This solution was rejected. Instead, CommDoo has reproduced the provider's complete contact form in order to enable the seamless processing of payment methods. If the customer now selects the function Answer collection discs in the menu bar of the website, a CommDoo iFrame appears in the look and feel of the merchant, which takes up the entire page. On the iFrame, all the debtor's contact details are requested and various options for action are shown, especially direct payment. The provider is informed about every action of a debtor by mail and http-call, so that the data can be processed automatically. |
| Development of a data hub for order management |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.juvia.de |
| Project partner |
| Even on Sunday, e-velopment, Wirecard |
| Abstract |
| For a successful fashion start-up, CommDoo has enabled an order management integration without programming effort. |
| Challenge: Integration of CommDoo into an OMS (360 e) without programming effort |
| At the request of the merchant, the functions Capture and Refund for the payment types VISA, Mastercard, AMEX, PayPal and Amazon Payments should be processed via the CommDoo Payment Gateway. A corresponding interface was not yet integrated in 360 e. Ideally, the implementation should take place without any programming effort on the part of the customer. Furthermore, a uniform format for the Electronic Payment Advice (EPA) should be defined for all these payment methods. |
| Implementation |
| In order to minimise the effort for the merchant, it was agreed that the 360 e CommDoo Payment Gateway would call up an already existing interface. The interface chosen was the one from Wirecard, which as a credit card acquirer was already an integral part of the project team. Likewise, Wirecard's EPA format, which is already integrated in 360 e, was specified as the uniform standard for all EPA files. Subsequently, CommDoo succeeded in mapping all formats of the various providers to the Wirecard format within a few days. |
| Development of a data hub for a PSP change |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.wolford.com |
| Project partner |
| Hermes Fulfillment, Klarna |
| Abstract |
| For an internationally active fashion supplier, CommDoo has enabled a PSP change without programming effort. |
| Challenge: PSP change to CommDoo without programming effort |
| Wolford's European business and its US business were processed via different shop systems and different payment service providers. CommDoo was PSP for Europe, Eos Payment for the USA. After the announcement of Eos Payment to discontinue its own platform, the USA business was also to be processed via CommDoo. First offers of the technical service provider for the USA shop were in the high five-figure range and put the entire project into question. CommDoo was commissioned to develop a solution - ideally without any programming effort on the part of the shop operator. |
| Implementation |
| In consultation with all parties involved in the process, a special mapping logic for Eos Payment was developed in the CommDoo Payment Gateway. With the help of this logic it was possible to address the CommDoo Payment Gateway with all payment interfaces of Eos Payment already integrated in the Wolford USA Shop. The effort on Wolford's part was limited to the exchange of the URLs with which the corresponding functions were to be addressed. All intelligence was outsourced to the CommDoo data hub. Thanks to CommDoo's experience with comparable projects, the entire process was completed in less than four weeks, including testing. |
| Development of an individual Klarna integration into an OMS |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.wolford.com |
| Project partner |
| Hermes Fulfillment, Klarna |
| Abstract |
| CommDoo has developed an individual Klarna integration into the OMS for an internationally active fashion supplier. |
| Challenge: adapting the Klarna world to the merchant world |
| Klarna Payment Methods in its complete form is a great challenge for every merchant. Particular difficulties regularly arise when it is necessary to hand over a clean shopping cart for partial captures and partial refunds, which must not deviate from the order in the web shop in any article specification. First cautious calculations showed that a corresponding implementation in the Order Management System (OMS) requires a high 5-digit investment. Consequently the choice fell on CommDoo, when it was necessary to develop an alternative solution without own investment expenditure. |
| Implementation |
| After CommDoo had carried out a complete inventory of all available data and data exchange formats in the first step, a process was defined in consultation with Hermes. Partial captures and partial refunds could be initiated from the OMS without a shopping cart using a simple token. A synchronous transfer to Klarna did not take place. Instead, the text files were first retrieved from an external FTP server, which was used to synchronize the inventory between the OMS and the shop. These were then merged with the orders for partial captures and partial refunds, so that a format could be created that Klarna could process. |
| Development of an individual SEPA direct debit integration |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.lascana.de |
| Project partner |
| Commerzbank Hamburg |
| Abstract |
| CommDoo has developed an individual SEPA direct debit integration for a large national fashion provider. |
| Challenge: Implementation of a two-step payment process for SEPA Direct Debit |
| For payment methods such as credit card, PayPal, Amazon or also Santander invoice purchase and Klarna invoice purchase, a two-stage payment process is regularly used: In the shop, payment is only pre-authorized and only completed by a so-called capture when the goods are shipped. This often results in lower fees and, above all, higher customer satisfaction. On the other hand, there are payment methods where a payment is completed directly in the shop. The SEPA direct debit also belongs to these payment methods. Since all processes at Lascana were designed to handle only two-stage processes, CommDoo was instructed to turn the SEPA direct debit into a two-stage process. |
| Implementation |
| Two-stage payment processes have already been carried out via the CommDoo interfaces already in use. These interfaces had to be extended in such a way that payments via SEPA Direct Debit are also exclusively pre-authorized and not completed. Due to the lack of corresponding functions at the connected banks, the process of pre-authorization had to be completely simulated in the CommDoo gateway, where all payment data is now securely stored after an intensive risk assessment with the participation of various information parties. A token-controlled process has been established for the actual booking from the Order Management System. A simple call with the ID of the pre-authorization is now sufficient for the now-booked order to CommDoo. The booking file for the SEPA direct debit is then generated in real time. |
| Development of a telephone-supported billing system |
| Product Branch |
| Telecommunications |
| Principal |
| www.telekom.de |
| Project partner |
| Deutsche Telekom AG |
| Abstract |
| A telephone-supported billing system (Pay By Call) was developed for one of the largest telecommunications providers in the world. |
| Challenge: Optimizing the conversion of the in-house payment system T-Pay |
| With T-Pay, Deutsche Telekom AG had already developed a very ambitious payment system with great potential very early on. The main difference to a competing system like PayPal was the wide range of different payment methods that could be used. In addition to credit card, direct debit and Micromoney (prepaid card), these included Call and Pay, a telephone payment option available only to registered Telekom customers. It was soon discovered that a telephone payment system allows a very good conversion for spontaneous purchases, but no such product was available for non-Telekom customers that could also function without registration. |
| Implementation |
| Premium rate numbers (value-added numbers) were already in use for several years in the form of 0190 and later 0900 numbers for the billing of telephone consultations at higher rates. For many years CommDoo programmed and operated a system for the Deutsche Telekom, where the caller did not call a consultant but simply a server. The server accepted the call and informed the caller by voice message how many minutes he had to stay on the line until the desired billing amount was reached. rights, the CommDoo solution quickly became the most successful payment solution in the T-Pay portfolio. A further developed technical solution for billing via premium rate numbers is still successfully used by CommDoo today under the names Pay By Call and MultiCall for the optimization of conversions when paying for digital goods. |
| Development of a crossgrade system for memberships |
| Product Branch |
| Digital goods |
| Principal |
| none |
| Project partner |
| Wirecard |
| Abstract |
| CommDoo has developed a system for the crossgrade of memberships for a large service provider. |
| Challenge: Intelligent increase of the Customer Live time Value (CLV) |
| Upgrade and crossgrade are features that can significantly increase the revenue per member. An upgrade only raises an existing membership to a different level; e.g. a 3-month membership can be upgraded to a yearly membership. In the case of a crossgrade, the change from one membership to another membership with changed services; for example, an ADAC membership can be converted to an ADAC-Plus membership. The following requirements were associated with the order to CommDoo: maximum simplicity of technical implementation for the provider and crediting of the remaining term to the original fees. |
| Implementation |
| The information on all existing basic memberships was stored in the CommDoo system. The complete runtime and direct debit management was carried out by CommDoo. Unsuccessful debits were retried up to four times before a dunning process was initiated. For the crossgrde of these memberships the provider was provided with a simple tokengestützter call. Just by passing the parameters membership number, new amount and new duration he could trigger all desired processes: Immediate cancellation of the old membership, immediate termination of the new membership, crediting the remaining term of the old membership to the original fees, automatic change to the new fees after the remaining term has expired and notification postbacks (webhooks) for all these events. |
| Development of a three-stage comprehensive risk management system |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.mustang-jeans.de |
| Project partner |
| Wiethe Group, Scholz Logistcs |
| Abstract |
| CommDoo has developed an existing customer monitoring system for risk management for a nationally active fashion provider |
| Challenge: Maximizing conversion while strictly controlling risk |
| In most cases, the choice of purchase on account is a strategic decision of the business management: On the one hand, the purchase on account is a self-directed process with increased effort, but also the control over the communication with the own customers. On the other hand the secured purchase on account, where the effort is lower but also the control over the communication with the own customers is lost. Mustang decided to do this on its own, under the condition that the loss would not exceed the cost of an external provider. The order for the set-up of a corresponding system was placed with CommDoo |
| Implementation |
| The core element of any risk assessment is data from one of the information providers represented in Germany, such as the German credit investigation agency Schufa. What they all have in common is that the fee for a query is high. The sum of these queries was therefore to be minimized. This was achieved by configuring three different check routines on the CommDoo risk platform. These were connected in series in such a way that the most favourable query always came first. In step 1, order data was compared with the available inventory data (inventory customer monitoring); here, the results of previous checks and the resulting individual limits for orders and open items were also taken into account. Step 2 included over 30 velocity checks to detect fraud patterns (anti-fraud). Only in step 3 were customers who could not be evaluated in the first steps subjected to scoring. |
| Hosting and billing of a telephone-supported hardware test |
| Product Branch |
| University, Medicine |
| Principal |
| www.audibene.de |
| Project partner |
| none |
| Abstract |
| CommDoo has developed a telephone handset test for the world's largest provider of lost property consulting services. |
| Challenge: Reduction of process costs for hearing tests. |
| audibene is the world's largest contact point for loss and damage to property, with over three million hearing aid consultations per year. Services include free expert advice over the phone and testing of the latest equipment at your local dealer. As an additional service, customers should be offered a simple but scientifically sound telephone test, which every audible partner can carry out during a consultation with their customers. At the end of each consultation, the results should not only be announced to the caller on the phone, but also sent to the consultant by e-mail. |
| Implementation |
| At the beginning of a test, each end customer receives a PIN from his consultant, which is stored in the audibene ticket system. Afterwards, the customer calls one of the telephone numbers connected to CommDoo and is requested to enter the PIN. Thereupon the CommDoo telephone server plays an audio file with numbers, which the customer must enter on his keyboard. If the customer recognizes the numbers correctly (wrong), an intelligent algorithm ensures that the next audio file is played more unprotected (more beautiful). This process is continued until the assets can be reliably determined. At the end CommDoo generates a mail with the encrypted result, which the audible ticket system can assign by PIN. |
| Development of a manual transaction management |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.dfb-shop.de |
| Project partner |
| DHL, Gothia Group |
| Abstract |
| CommDoo has developed a solution for manual transaction management for the world's largest sports federation. |
| Challenge: Reduction of process costs in the execution of returns |
| For many years, the merchandise management of the DFB Shop was ensured by Ernst Schmitz Logistics. Based on the eFulfilment platform (today: eF|CommerceEngine (eF|CE)) all payment related processes around order management (capture and refund) between CommDoo and Scholz Logistics were fully automated. With the change to DHL these processes were interrupted. A quick solution was needed to bridge the time until the reactivation of the automated processes. |
| Implementation |
| Via the online manager of the CommDoo (www.commpay.net) a multitude of functions could already be used. Up to now it was not possible to cancel authorized payments via PayPal or credit card or to carry out any number of bookings (capture) for authorized payments and subsequently also credit notes (refund). These functions were activated by CommDoo within a very short time. Combined with an intelligent rights management, it was ensured that only specially trained DHL employees had access to these sensitive functions. |
| Development of a fraud protection system for telephone payments |
| Product Branch |
| Digital goods |
| Principal |
| none |
| Project partner |
| IN-telegence |
| Abstract |
| For a large provider of digital goods, CommDoo has developed protection against payment defaults for telephone-based payments. |
| Challenge: Reducing the default risk of phone-based top-ups |
| In order to be able to use the services of the provider, the customers have to load a credit balance in advance. A variety of payment methods are available to them for this purpose: Credit card, SEPA direct debit, Paysafecard, PayPal, Webbilling, Bitcoin, Sofort&ueberweisung, giropay, ideal, eps, Postfinance and also PayByCall for all German speaking countries. In particular with telephone-supported top-ups (PayByCall) via the German fixed network, there were always sensitive payment defaults. CommDoo was asked to develop a system with which the risk of payment defaults could be minimized. |
| Implementation |
| In order to be able to assess the risk of the telephone payment process even before the call is accepted, the telephone carrier calls the CommDoo server via http request and cancels the call. CommDoo compares the transferred information such as the telephone number with its own blacklists. In addition, specially programmed velocity checks are used to check the data for fraud patterns: if there are more calls with this number, there are more calls from a certain area code, there are more calls from a certain 10 or 100 block, there are more calls from certain networks, etc. As a result CommDoo determines an individual limit, which is transmitted to the telephone carrier in the form of a permitted call duration. This duration is announced to the customer before the call. |
| Development of a smart-routing system for credit cards |
| Product Branch |
| Finances |
| Principal |
| none |
| Project partner |
| none |
| Abstract |
| CommDoo has developed an intelligent acquirer control system for a PSP specialising in financial products. |
| Challenge: Minimizing risk while maximizing conversion |
| High deposits in order to do financial business stand for a high-risk business model. In this case, the depositor must therefore not only overcome the in-house fraud protection system for credit cards but also the particularly sensitive risk checks of the credit card acquirers. In addition, there are strict limits for transactions and chargebacks for the individual credit card acquirers. A system was commissioned with which up to 5 different acquirers can be addressed according to clearly defined rules in order to achieve maximum payment conversion in combination with an intelligently controlled risk. |
| Implementation |
| At the beginning, a catalogue of criteria was defined, with which the control of the acquisitions (smart routing) is to be carried out, if a customer had previously successfully overcome the CommDoo Frau protection logic. Among the parameters were : Amount amount, country, card type, number of transactions in defined periods of time per acquirer and card type and country, amount of sales in defined periods of time per acquirer and card type and country, and number of chargebacks in the defined periods of time per acquirer and card type and country. As a result, the customer was booked with one acquirer and registered with at least one and a maximum of four other acquirers to receive a virtual card number (token). In a subsequent booking, the customer could then choose between up to 5 different acquirers without having to query the card data again, depending on the result of the smart routing logic. |
| Development of a multiple payment checkout for SEPA direct debit (SEPA Secure) |
| Product Branch |
| Digital goods / Entertainment |
| Principal |
| none |
| Project partner |
| none |
| Abstract |
| CommDoo has developed a SEPA direct debit check-out with different funnels for a large provider of digital goods. |
| Challenge: Maximizing conversion while strictly controlling risk |
| The use of SEPA direct debits for digital assets is a minor discipline of payment. It is an offline payment, where the booking on the customer account is delayed. Thus, every transaction is subject to risks: does the account actually exist, is the account covered, does the account really belong to the client, etc. The higher the booking amount and the cumulative booking amount, the greater the temptation for customers to return funds. The assignment for CommDoo was to develop a system in which each customer has to go through exactly the SEPA Check-Out that corresponds to their individual risk profile. Despite high-risk business, the re-booking rate must not exceed 10%. |
| Implementation |
| The system developed by CommDoo is based on two modules: risk types and layouts. Risk types are a special combination of test routines that are run through in a fixed sequence. Checks are e.g. plausibility checks (address, bank data etc.), velocity checks (identification of fraud patterns), strict limit checks on various levels or credit checks. Layouts are payment windows where customer data is requested. On simple layouts, only the IBAN is queried, on complex layouts all personal data is also queried. In addition, high-risk verifications such as SMS PIN or account login are required. Already when calling up our payment window, it is recognized whether it is a new or existing customer and depending on various parameters such as amount, time, age and experience a selection of suitable funnels is made. Subsequently, each risk type that is passed through refines this decision until the perfect funnel is found at the end. |
| Development of an application for electronic & postal invoice dispatch |
| Product Branch |
| Mail order business, cosmetics |
| Principal |
| www.kosmetikfuchs.de |
| Project partner |
| Santander Consumer Bank, Easybill |
| Abstract |
| CommDoo has developed a system for the external dispatch of invoices for a large sender. |
| Challenge: Change of supplier for invoice purchase without changing the existing processes. |
| Many providers of secure solutions for invoice purchase, such as Klarna, Ratepay or Billpay, buy the receivable and send the invoice to the end customer. With other providers, such as Santander, the invoice dispatch remains in the hands of the retailer. The retailer then informs the customer on his invoice that he does not have to pay the retailer but directly to the buyer of the invoices. For this purpose, the merchant will receive from the supplier, after completion of the transaction in the shop, a purpose for payment which he must indicate to the customer on the invoice. And it was precisely this process for which the systems of the client of CommDoo were not prepared. |
| Implementation |
| The retailer used Shopware 5 and BüroWARE. The processing of payments for the payment methods Santander purchase on account, credit card and PayPal was to be carried out via finished shop extensions from CommDoo. In order to be able to send invoices for Santander purchases on account, the Shopware REST API of CommDoo was addressed. As soon as the status of an order was set to sent, the CommDoo gateway generated an order to send an invoice to Easybill. The invoice data from the merchant system was merged with the purpose of the Santander, which was temporarily stored in the CommDoo Gateway. |
| Development of an electronic payment notification (EPA) harmonised across all payment methods |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.tom-tailor.de |
| Project partner |
| Hermes Fulfilment, Wiethe |
| Abstract |
| On behalf of one of the largest fashion brands in Germany, CommDoo has developed a solution for harmonized EPA files |
| Challenge: Reduction of process costs |
| Electronic payment notifications (EPA) or reconciliation files allow the automated booking of sales and fees at the debtor level. All providers of electronic payment systems have their own formats and many of these formats are complex. This makes both the integration into the merchant systems and the regular maintenance extremely costly. As a result, most retailers do not integrate with the system and charge for it on a domestic basis, which results in high process costs. In order to reduce the effort of EPA integration to a minimum, CommDoo was asked to develop a harmonized EPA format that is easy to integrate. |
| Implementation |
| In coordination with the client's accounting department, the formats from different providers were analyzed and the parameters required for accounting were identified. Based on this, a transparent EPA format was developed, which exactly reflects these parameters. Finally, the formats of different payment providers were mapped exactly to this format. The daily processing of the mapping is done in the CommDoo gateway. The CommDoo EPA format processes payments from various credit card acquirers as well as from Klarna, Amazon Payments or PayPal. The processing can be done in all accounting systems, there is also a special adapter for DATEV. |
| Development of a secure data transfer by e-mail for an insurance company |
| Product Branch |
| Insurance |
| Principal |
| www.advocard.de |
| Project partner |
| GFKL Gruppe |
| Abstract |
| CommDoo has developed a system for secure data transfer for one of the largest providers of legal protection insurance. |
| Challenge: Automation of processes without direct communication between systems |
| The automated exchange of customers and paid employees with companies in the insurance industry is subject to special challenges. This often requires an NPP (New Product Process). For the provider who wanted to market an innovative form of immediate vehicle purchase protection online, the question therefore arose of how he could implement both online payment and all communication with his administration systems in such a way that he had to make the least possible intervention in his own process landscape. After intensive market research, the choice fell on CommDoo as the service provider for payment processing. |
| Implementation |
| The order was placed in a four-step process: select service, enter personal data, display result, make payment. To execute the payment, CommDoo recreated the complete website, i.e. no iFrame was loaded by CommDoo, but a redirect to an exact copy of the Advocard page hosted by CommDoo followed. The buyer could not perceive any difference. After completing the payment on the CommDoo Payment Page, the buyer was redirected back to the shop without giving any payment data to the shop. These scents were exclusively transferred to the administration systems, but without using automated interfaces. CommDoo therefore developed an e-mail-supported data exchange process in which the mails were not only certified but also encrypted several times. |
| Development of a Pay By Call solution with variable pricing (www.multicall.de) |
| Product Branch |
| Digital goods |
| Principal |
| none |
| Project partner |
| none |
| Abstract |
| CommDoo has developed a Pay By Call system with variable pricing for a large provider of digital goods. |
| Challenge: improving the conversion of telephone-based payment methods |
| For so-called Premium Rate numbers (in Germany 0900) tariff restrictions apply. These restrictions apply to minute-based billing (in Germany e.g. 2.99 €/minute) and to one-time payments (in Germany e.g. 30 €/call). Minute-based billing is used when the buyer can decide variably how much he wants to top up his credit. One-off payments per call are used when the provider gives the customer tariff options. If these tariff options are above the tariff restrictions (e.g. 30 € in Germany), the provider has to hide this extremely conversion-furthering payment option. CommDoo was commissioned to develop a solution for this. |
| Implementation |
| Premium rate numbers are subject to fixed tariffs. In order to handle only the conceivable options from 0 € up to the upper limit of the tariff, an infinite number of numbers per country may be required. To avoid this, the CommDoo system provided that the customer could call not only once but several times (MultiCall). In this way, not only all conceivable tariffs up to the upper limit of the tariffs could be mapped, but also beyond that. User guidance was provided via a specially designed payment window from CommDoo, which minimized the probability of aborts due to a number of intelligent features (including gamification elements). Example: For the amount of 35,90 € in Germany, phone numbers had to be called at 30 €/call, 5 €/call and 2,99 € /minute, whereby the last call was interrupted after exactly 20 seconds. |
| Development of a data hub for the accounts receivable |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.monari.de |
| Project partner |
| ideal Fulfillment, myfactory |
| Abstract |
| CommDoo has developed a connection to the accounting system for a large national supplier of ladies' fashion. |
| Challenge: Automation of the accounting processes |
| More and more often, providers of online services entrust their accounts receivable accounting to specialized external partners. This has the advantage that the systems used there regularly map a much broader spectrum of functions. On the other hand, the set-up process is much more time-consuming, as the complete chart of accounts has to be stored once. Likewise, processes must be defined for the ongoing data exchange. This usually takes place directly between the provider and the third-party company responsible for accounting. However, such an interface was not provided in this project. Thus CommDoo was commissioned to ensure the data exchange via the CommDoo Payment Gateway. |
| Implementation |
| For the implementation two questions had to be answered. How does the ongoing data exchange with the external accountant take place (ideal Fulfillment) and how does CommDoo obtain all the data required for accounting. With regard to the data exchange, it was clear relatively quickly that CommDoo would integrate an existing standard interface of the accounting program my factory into its system due to the available developer capacities. With regard to the required data, a large amount of the required information, such as customer numbers and product codes, could be taken directly from the payment process. It proved to be an advantage that all payment transactions were processed using CommDoo's own shopware extensions developed in-house. All information required beyond that was retrieved by CommDoo via REST API directly from shopware. |
| Development of a Rebill solution for SEPA direct debits |
| Product Branch |
| Digital Goods / Consulting services |
| Principal |
| www.aximus.ch |
| Project partner |
| none |
| Abstract |
| CommDoo has developed a Rebill solution for SEPA direct debits for a large provider of digital goods. |
| Challenge: Increase conversion through simplified reill functionality |
| In business models with actual added value for the customer, rebills are taken into account from the outset when calculating the customer acquisition costs (PER). Rebills for SEPA direct debits are usually processed as follows: Either the customer has to re-enter his SEPA data each time or it is booked directly with the help of a token by one-click. The provider, who provided a technical platform for many of the largest German newspapers, found the first option too complex and the second too risky due to the chargeback risks. He commissioned CommDoo to develop an interim solution for him. |
| Implementation |
| For the first booking via SEPA direct debit, customers were subjected to a comprehensive risk check. Within the scope of these risk checks, the customer also had to authenticate himself with an SMS PIN or telephone PIN automatically generated by CommDoo. The authentication was carried out on a specially developed payment page. The provider now also wanted to use this PIN as authentication for Rebills. For this purpose CommDoo developed a check-out process in which each customer only had to enter the bank data in step one. If CommDoo recognized the bank data, the customer was asked to confirm the payment with the PIN known only to him. If CommDoo did not recognise the bank data, the customer was treated as a first-time customer. |
| Development of a smart routing solution for credit cards for memberships |
| Product Branch |
| Digital Goods / Online Dating |
| Principal |
| www.wowdating.net |
| Project partner |
| none |
| Abstract |
| CommDoo has developed a Smart Routing Service for memberships for a large online dating provider. |
| Challenge: Increasing Customer Livetime Value (CLV) for memberships |
| There are different business models in online dating. In the classic dating agency, billing is almost exclusively based on memberships. In casual dating or flirt portals there are offers with memberships as well as offers with one-time payments. For memberships, credit cards (all countries) and SEPA direct debits (especially DACH) are used. In the case of long-standing memberships via credit cards, it happens regularly that the booking of a recurring fee (Recurring) for a membership cannot be carried out successfully. For this reason the provider is looking for a solution. |
| Implementation |
| CommDoo operates its own solution for memberships. To meet the requirements of the provider, CommDoo has developed a multi-level solution for card payments. When the membership is concluded, the card is registered with up to 4 different acquirers to receive a virtual card number for bookings (tokenization). Afterwards, the first booking is carried out at one of the acquirers following a defined logic. If the subsequent booking fails, the booking is attempted with the other acquirers using the token. If this also fails, the process is retried for up to 5 days, depending on the reason for rejection (especially insufficient funds). As a result, the number of rejections has been reduced by more than 25%. |
| Development of a risk check solution for card payments in the USA |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.wolford.com |
| Project partner |
| none |
| Abstract |
| CommDoo has set up a risk management for the USA for an internationally active fashion supplier. |
| Challenge: Reducing the risk of default while protecting the conversion. |
| In contrast to credit card transactions in Central Europe, credit card transactions in many other countries are much more at risk of being charged back by buyers. These countries include the USA, where the supplier has been selling its products for many years. Prior to his move to CommDoo, he had to deal with a considerable number of chargebacks, which led to high losses. CommDoo was given the task of developing a fraud protection system that would minimize the losses without having to use 3-D Secure with its negative consequences for the conversion. |
| Implementation |
| CommDoo is one of the few payment providers that has developed its own risk platform. In consultation with the provider, it was decided to set up a five-stage system based on the existing CommDoo modules in order to minimize chargebacks: These stages were formal and logical plausibility checks, blacklisting and whitelisting, geo-checks, scoring and fraud pattern detection with velocity checks. In total, almost 20 different check routines were used within these risk check groups, which were permanently monitored and their configuration was adjusted. In case of doubt, a mail was sent to the provider for manual checking. As a result, it was possible to reduce the execution almost to 0. |
| Premium Rate phone number |
| Product Branch |
| Happiness |
| Principal |
| City of Marburg |
| Project partner |
| none |
| Abstract |
| On behalf of the city of Marburg to make a red heart shine. |
| Challenge: To make people a little bit happier. |
| On the Spiegelslustturm in Marburg a large heart of light elements was installed. In order to cover the costs, the lighting elements were to be activated via a premium rate telephone number for a defined period of time. |
| Implementation |
| Visitors to the tower are shown a poster with a phone number to call to activate the mechanism. After a call is received on the CommDoo telephone system, the mechanism is activated by a pulse for a short period of time. A red heart starts to glow. |
| Development of a repeat logic (hope run) for subscription payments |
| Product Branch |
| Digital Goods / Online Dating |
| Principal |
| www.jamble.com |
| Project partner |
| none |
| Abstract |
| For an online dating portal with memberships, Commdoo has developed an intelligent hope run. |
| Challenge: Increasing Customer Lifetime Value (CLV) through customer-friendly handling of chargebacks |
| Memberships are regularly charged by credit card, direct debit or PayPal. In the course of a membership it can happen even to the best members that a direct debit could not be collected due to lack of funds. Especially with these good members it should not happen that accesses are blocked and reminders are sent automatically. Instead, an attempt should be made to collect the amount again. |
| Implementation |
| Together with the retailer, criteria were defined to identify the customers who should be charged again in a run on hope. Such criteria include the duration of the membership, the number of successful direct debits to date and the specific reason for the reversal given by the bank. If all defined settings apply to a member, the member will be informed by e-mail about the new debit. The time of the hope run can be set as desired. |
| Development of an individual and intelligent payment window with 10 micropayment methods |
| Product Branch |
| Digital Goods / Browsergames |
| Principal |
| www.bundesliga.de |
| Project partner |
| Aitainment GmbH |
| Abstract |
| For the official Bundesliga manager, CommDoo has provided an individual payment window with 10 payment methods. |
| Challenge: Development of an individual and intelligent payment window with 10 micropayment methods |
| More payment options are used for digital goods than for mail order. Three points are responsible for this: There are actually more ways to pay for digital goods. There are more spontaneous purchases and with these, end customers like to use "their" favourite payment method. Finally, the differences in micropayment fees are sometimes considerable. Against this background, the client has defined a portfolio of payment methods that are to be used with margin options. |
| Implementation |
| An individual payment window was developed according to the design specifications of the client. The payment methods offered on this window are automated and put together individually for each end customer. The following criteria are used: product type (subscription or one-off payment), amount and risk profile. Among others, credit card, direct debit, PayByCall, Carrier Billing, Sofortüüberweisung, giropay, PayPal, Paysafecard are offered. |
| Development of a prepaid and postpaid system for telephone consultations |
| Product Branch |
| Life Counselling |
| Principal |
| www.zukunftsblick.ch |
| Project partner |
| In-telegence GmbH, Peernet GmbH |
| Abstract |
| CommDoo has developed an innovative pre-paid system for telephone services on behalf of an internationally active provider of life advice. |
| Challenge: Increase conversion through alternative payment methods. |
| The client operates a portal for life counselling. The majority of his end customers come from the countries Germany, Austria and Switzerland. Traditionally, the services were charged only via telephone-supported payment methods, in particular 0900 Premium Rate Services. The acceptance of these payment methods has been slightly declining for years and the fees are high. Customers should therefore be given alternative payment options: All customers should be given the opportunity to make phone calls from a previously loaded credit (prepaid). Regular customers should also have the possibility to make phone calls on account. |
| Implementation |
| The CommDoo gateway contains a complete credit management. Up to 6 different payment methods are available for topping up. The credits can be linked with any criteria. Relevant for the project are the telephone numbers of the end customers. A real-time connection to the telephone switch of Intelegence GmbH was established via interfaces. If a customer calls one of the telephone numbers displayed on www.zukunftsblick.ch, an authorization request is sent to CommDoo, which releases the call (with credit in minutes) or rejects it. After the end of the call, IN-telegence is called up again at CommDoo with information on the duration of the call so that the customer's credit can be updated. The client has been provided with a number of interfaces with which he can query or change credit balances and other payment data. |
| Development of an automated credit note system for immediate transfer |
| Product Branch |
| Mail order / DIY store |
| Principal |
| www.hellweg.de |
| Project partner |
| Agency |
| Abstract |
| On behalf of one of the largest DIY stores in Germany, CommDoo has developed a solution for automated credit notes with immediate transfer |
| Challenge: Reduction of process costs |
| From the order management system (OMS) used, credit notes for PayPal and credit card could be automatically generated via the CommDoo system. With both payment methods, CommDoo can communicate directly with the systems of the providers and carry out the crediting in real time. There was no comparable solution for instant bank transfer. Here Hellweg had to search out the bank data manually and carry out individual transfers. This process was to be superseded by a process identical to the credit card and PayPal process. |
| Implementation |
| After completing each transaction with immediate transfer, the bank data is securely stored in the CommDoo Financial Data Hub. When the OMS calls up the Credit function, CommDoo generates a form for a SEPA transfer with the help of the stored data. These forms are provided to the client in real time or collected at specific times upon request. The forms are made available in a way that allows an automated import into the client's banking systems. |
| Automated resolution of risk checks in pending status |
| Product Branch |
| Mail order / Fashion |
| Principal |
| www.takko.de |
| Project partner |
| Emakina |
| Abstract |
| On behalf of one of the largest fashion retailers in Germany, CommDoo has developed a solution for simplification at Klarna. |
| Challenge: Increasing the conversion through a better acceptance rate for risk checks |
| Not every authorisation request can be answered automatically by the Klarna system. A small part is reported back as pending. The approval or rejection is delayed. Accordingly, a shop must be able to deal with delayed replies and the status pending. This was not the case with Takko. Therefore, a solution was sought in which all risk checks could be performed without having to make extensive adjustments in the Takko shop. |
| Implementation |
| All transactions in the purchase on account are processed via a takkoindividual payment window (Hosted Payment Page). In case Klarna reports the status Pending during a risk check, the end customer is kept on the payment page until Klarna resolves the status Pending and reports either accepted or rejected. For this purpose, the CommDoo gateway queries Klarna for the current status several times per second. The resolution takes place after 2 seconds on average. After that the customer is immediately redirected to the Takko webshop. |