Laravel development services for Dutch companies

Dutch projects tend to arrive with an assumption that the market is close enough to the German or the British one to reuse the same design. The legal frame is similar. The plumbing is not, and two pieces of it reach far enough into the schema to be worth settling early.

iDEAL is not a card, and the difference is structural

Most of the Dutch market pays by iDEAL, and an order model built around card payments fits it badly - not because of an API difference but because the payment method genuinely works another way.

There is no authorisation and capture. A card payment lets you reserve funds now and take them when the goods ship. iDEAL is a bank transfer: it either happened or it did not, at one moment, for the full amount. Any flow that assumed a hold - pre-orders, deferred shipping, adjust-then-charge - needs a different shape.

There is no refund on the original transaction. A refund is a fresh transfer in the other direction, with its own timing and its own failure modes, which means your order state has to distinguish "refund issued" from "refund settled" rather than flipping a boolean.

There is no stored credential to charge again. Recurring billing needs a direct debit mandate set up as a separate flow with its own consent, so anything with a subscription in it has two payment integrations rather than one.

And the result arrives by webhook, possibly after the customer has closed the browser. The status the redirect suggests is not the status - the webhook is, and it needs to be idempotent, because it will arrive more than once.

None of this is difficult. All of it is expensive to discover after the order table exists.

Peppol is a network, not a file format

Electronic invoicing in the Netherlands runs over Peppol, and the distinction from "generate an XML file" matters. Peppol is an addressed network with accredited access points: you connect to one, your customer connects to another, and documents are exchanged between them. Your application's job is to produce a valid document and hand it to your access point.

Two consequences for the schema.

Every party needs an identifier that is not their name. In the Dutch context that is usually the KvK or a VAT number expressed as a Peppol participant id, stored as a field rather than assembled when an invoice is generated.

Validation happens before sending, and it is strict. A document that is missing a required field is rejected by the network rather than by the recipient, which is better - but it means invoice generation needs a validation step and a state for "built but not accepted", not an assumption that writing the file is the end of the process.

For central government suppliers this is already obligatory. For everyone else, the practical trigger is a large customer asking, and the gap between "we should look at that" and "we need it next month" is where the rushed version gets built.

The regulator reads what you wrote

The Autoriteit Persoonsgegevens is among the more active data protection authorities in Europe, and its attention to consent is not theoretical.

For a backend that mostly means two things. Consent needs a record with a history - when, for what, and what happened when it was withdrawn - rather than a boolean on a row. And the right to erasure needs to be an operation the system performs, with an explicit list of what is retained anyway because tax law requires it, rather than a developer writing SQL and hoping.

Both are the same decisions any EEA build should make. The difference here is the probability of being asked to demonstrate them.

Names, which sound trivial and are not

Dutch surnames carry tussenvoegsels: the particles between the given name and the family name. Sorted properly, "Vincent van Gogh" files under G. Stored in one name column, it files under V, and every alphabetical list in your application is subtly wrong to every Dutch user looking at it.

The conventional answer is three fields rather than two. It is a five-minute decision at design time and a data migration with guesswork in it afterwards.

Working with us from the Netherlands

We work remotely from Ankara, an hour ahead of Amsterdam, in English.

The engineering is our usual application development and API work. What a Dutch engagement adds is that the payment model, the invoicing network and the shape of a person's name are all decided before the first migration, because each of them is a schema decision wearing a local costume.

Dutch teams reach this conversation from Python more often than from PHP. Where Laravel and Django actually differ is not where the framework arguments usually put it. The iDEAL and Peppol work is the same either way; what changes is who maintains it afterwards.

Invoicing and payment. In euros, by bank transfer to an IBAN. Codefacture Yazılım A.Ş. is registered in Türkiye, so the invoice carries no Turkish VAT under the export-of-services exemption. We are not on the Peppol network ourselves, so what reaches your inbox is an ordinary PDF.