From development: identity checks, attacks, AI, and phone

Five topics are in development at the same time. They belong together, and none of them is only an appendix to another: identity checks at checkout, defence against targeted attacks, the AI system in support, the phone agent, and the milestone for version 3.0 of the shop software.

The detailed point values for identity checks also sit in their own article: Identity checks: the rules that apply, the score, and the partner. Where the two texts disagree, this article applies. It is the later account.

Identity checks

Since 29 September 2026 we score private-customer orders from 0 to 100. The score is an internal measure of how well the details of an order fit together. It is not a judgement of you as a person.

Points come from the connection, from countries, from names, from addresses, and from how often you order. Each signal counts once, at its highest value. Nothing above 100 is stored.

  • Below 80 points, with no specific reason in your case: nothing changes at checkout. Even 25 or 50 points do not hold the order. A warning is a note for us, not a block for you.
  • From 80 points, or if we ask for the check for a concrete reason: the order continues once the identity has been verified. Until that requested check is finished, this order does not go through.
  • You are already verified: we do not ask again on every order. If a new reason appears later, we can ask for verification again.
  • Quantity limits from the September article are not in force yet. We will name a start date beforehand, not after it has already begun.

Below 80 points we can still require the check if there is a concrete reason. Details may not fit together, someone else may be using the account, or there may be a hit on the block list. Without that kind of reason we do not require the check. This is set out in section 18 of the terms. If you think the decision is wrong, open a support ticket. We will review the case.

The check does not run inside the shop. A partner carries it out. At present that is Stripe Identity. The shop can also use another partner, for example IDnow. The flow shows you who is running the steps.

From you we need a photo ID, meaning a driving licence, identity card, or passport, and a selfie taken live with the camera on your device. Uploading a picture you already have is not enough. The document image and the selfie stay with the partner. We store the result, the name of the partner, and a case reference. You also confirm your email address and phone number with a code.

Block list and sanctions

  • If the email, username, or phone number matches a blocked account, we do not accept the order.
  • If the address is on our block list, the identity has to be verified before the order continues. That applies especially when the name is the same.
  • If the name only resembles an entry, that is 80 points. Verification is required then as well.
  • Sanctions list: if the name or address appears on a list that applies to us, verification is required too. We may decline the order. That has not happened yet. We do not ship to countries sanctioned by Germany.

An ordinary order whose details fit together continues as before. Verification is the exception with a reason, not the normal step at checkout.

Targeted attacks

We are under continuous, targeted attack. These are not the random bulk scans that hit any larger site. The attempts repeat, get tighter, and aim at the same places. From that pattern we believe someone with substantial IT skill, time, and money is aiming at us.

The attempts include SQL injection, cross-site scripting, and scans for environment and password files. Over time the requests get more precise, not wider. If these were the usual bulk scans, we would not be writing about them. We do not publish what a single request looks like. That kind of detail helps the next attempt, and it does not help customers.

This morning, on Tuesday, 13 October 2026, an attack on our caching infrastructure took the site down briefly. The shop was reachable again afterwards. We are not publishing the technical details of that either. What was affected was the availability of the pages, not your account and not a single order.

We do not rely on Cloudflare alone. The web server logs are monitored continuously. Suspicious requests are added to our own WAF. Our own AI system helps read these patterns. The servers run on our own infrastructure. If the load rises, we can scale vertically, which means more capacity on the servers we already run.

DDoS attacks remain a separate topic. They do not aim at a single flaw in the software. They try to make the shop unreachable by sheer load. That is not a one-off event we are equating with this morning. It is an ongoing subject alongside the targeted requests against the application. Here too, defence does not rest on Cloudflare alone. We can scale our own infrastructure vertically when the load rises. We do not promise that every wave will pass without effect. We are stating what the defence rests on, and that we move it with the load.

If you are reading this because you are the one running the attacks: this is wasted money, wasted time, and wasted energy. Every further attempt hits the same monitoring and tightens the defence. That does not make a breakthrough more likely. For everyone else: an ordinary order is not what these attacks are aimed at.

AI in support

In support we use an AI system that we operate ourselves. It consists of local models, an LLM router, and a privacy proxy. Those three parts run on our own infrastructure. Not every prompt leaves our servers. What a local model answers stays with us.

If a prompt goes to an external service, such as the OpenAI or Anthropic API, it goes through the privacy proxy. Customer data is pseudonymised first. Name, email address, phone number, and postal address do not appear in plain text in that prompt. Pseudonymised does not mean anonymous. A link can still exist on our side. The external service should not be able to rebuild that link from the prompt itself.

One concrete use is summarising support tickets. The summary helps us take in a longer request faster and handle it consistently. It does not replace what you wrote, and it does not decide whether an order is accepted or declined. The decision on an order stays a separate step, and you can ask support to review it.

Which data is processed, on what legal basis, and who receives it, is set out in the privacy notice, in the section on the self-operated AI system.

Phone

On the phone you reach the AI phone agent from Sipgate. It adds a way to reach us. It does not replace a support ticket, and it does not replace checkout.

At the start of the call it already has the public state of the shop. That includes opening hours, closures and company holidays, current news, common questions and the legal texts. It also includes the active shipping and payment methods with their descriptions, shipping prices and fees, and, for products that carry stock or a preorder, availability and the price of each variant, net and gross. It does not state stock quantities. Group prices apply only to a confirmed account and are not part of that first briefing.

During the call it can look things up in the shop, live. These are the functions, and nothing beyond them:

  • Account and status. Name, email and your most recent orders. On request, also whether your account is active, whether the email is confirmed, which customer group applies, whether two-factor sign-in is on, whether the age check is done, which language applies, and when the account was created.
  • Orders. One order, the latest order, or a list of your orders. An order can also be found from a ticket number or a tracking number. It states the short reference, the status, and whether it is paid and shipped. It states the amount only if you ask.
  • Shipment. Whether a tracking number exists, the current status, whether the parcel has been delivered, and the tracking link if you want to hear it. If there is no shipment, it says so and can offer a ticket.
  • Existing tickets. The open requests on your account, or a single ticket by its number, with the status and the last public message.
  • A new ticket. Only after you have heard the email, subject and text and said yes. It then tells you the ticket number. A question by itself does not create a ticket.

The phone number finds an account when it is stored there.

It does not disclose addresses, payment references or internal notes. It does not process refunds, address changes or cancellations.

If something stays unclear, the answer does not match your order, or you want to challenge a decision, you can still reach us through a ticket. Include the order number and the time of the call.

Shop software 3.0

We have started the milestone for version 3.0 of the shop software. That is the start of the work, not the release. There is no date yet. Until then the shop runs in the version you are using today. That version stays available until the move is finished.

Today the shop is one application. It sends the page to the browser and assembles it at the moment you open it. To do that it asks for content, customer data, and login, even when the page barely needs them. It also waits on APIs from other providers. Until one of them answers, the page is not finished. Those lookups run one after another in the same request. It stores the result in a cache so the next visit is fast. If the cache is still empty, or the content has changed, that visit takes a very long time, because the page is assembled only then, and it waits on those APIs while it does. After that it loads quickly from the cache. If the cache fails, the page fails with it. That is what happened on Tuesday, 13 October 2026, when an attack on that exact layer made the shop briefly unreachable.

In version 3.0 that application becomes the business API. It stays Phalcon, but it no longer sends HTML to the browser. The domain logic sits in that one place. The shop frontend becomes a slim Astro.js app. It only displays what the API returns. It has no domain rules of its own, and it does not talk to content, login, customer data, or the other services directly.

One call to the business API returns content and data ready to show. Page content arrives with the variables already filled in, the way you see the page today. What is fetched one after another from other APIs today is bundled into that single call. That removes the long waits that happen because forms and pages, inside the same request, wait on outside APIs in sequence.

The aim is shorter load times, including the first visit after a change. The page no longer waits by itself, lookup after lookup, on outside APIs. The API bundles that work.

Where this is written down

The identity check is in section 18 of the terms. The AI system, the phone agent, and the data processed for them are in the privacy notice.

Our products remain intended solely for scientific, analytical, and laboratory research.

Your Remicals.de Team

Only necessary cookies accepted

You have decided to accept only the necessary cookies - a choice that we fully understand, as protecting your privacy is our highest priority.

We respect this decision and therefore do not use additional tracking tools such as Google Analytics or similar analysis services. This means you can use our website without additional data being collected or passed on to third parties.

Your trust in the responsible handling of your data is important to us, and we do everything we can to offer you a safe and data protection-friendly visitor experience.