Custom WordPress website development in Zurich

Payments on a Swiss WordPress site usually take two forms. Buyers pay at checkout, often with TWINT on a phone. Or the business sends an invoice and waits for a bank transfer. Both need decisions early in the build. They touch the shop, the invoice template and the accounting export at once.

TWINT is the mobile payment app that most people in Switzerland already carry. On a desktop checkout it shows a code that the buyer scans with the app. On a phone the payment page hands over to the app and then back again. A shop that offers cards alone sends many buyers looking for their wallet. WooCommerce reaches TWINT through a gateway plugin from a payment service provider that supports it.

Choose that provider with care. Compare which methods it bundles, how refunds work, whether a partial refund for one item can be issued from the WooCommerce screen, and how payouts arrive. Then test the full round trip on a real phone. Pay, switch to the app, confirm, come back. The case to watch is the buyer who closes the app halfway and returns to a page that does not know what happened.

Invoices follow a different standard. The Swiss QR-bill, or QR-Rechnung, replaced the old orange and red payment slips, which banks stopped accepting in 2022. It is a payment part at the bottom of the invoice, built around a QR code with a Swiss cross in the middle. The buyer scans it in a banking app. Every field fills itself.

The layout is strictly defined. The size of the payment part, the perforation line, the fonts, the order of the fields and the size of the code all follow the Swiss Payment Standards. A PDF invoice plugin that pastes a generated image into a corner may produce a slip that some banking apps misread. Check that the plugin names the standard it implements and keeps up with its revisions.

Currency and amounts have rules too. A QR-bill carries amounts in CHF or EUR only, with two decimal places. If the shop sells in other currencies, the invoice logic has to decide what happens to such an order before the first one arrives.

The reference is the part that pays off later. With a QR-IBAN the bill carries a structured QR reference. With an ordinary IBAN it can carry an international creditor reference instead. Generate it from the order or invoice number so that each one is unique and has a check digit. Bank statement files then list every incoming payment with its reference, and bookkeeping software can match it to the right invoice without anyone reading names off a statement.

Reconciliation is where many WordPress builds stop too early. The shop marks an order as on hold while the invoice is open, and somebody has to mark it paid. Decide whether that stays manual, happens in the accounting software or flows back into WooCommerce through an import or an integration. Any of the three can work. An undecided one leaves orders stuck.

Test with real banking apps before launch. Scan the payment part from a screen and from a printed page, with more than one bank. Then send a small real transfer through the whole cycle, from invoice to matched payment, and read what arrives on each side.

WordPress ships with a REST API. Every public post, page, category and media item can be read as structured data at a predictable address. That helps when a mobile app, a screen in a lobby, a partner site or an internal tool needs the same content as the website. It is also something many site owners do not know is switched on.

Start with what is already public. The default endpoints list posts, pages and published media, which is fine. They also list user accounts that have published content, together with their slugs. Many teams hide that list or limit it to logged in requests, because it hands an attacker half of a login attempt. Custom post types appear only when registered with the API option enabled. Check each one on purpose.

Custom fields are the next question. They are not exposed by default. Register the fields another system actually needs, and nothing more. The response stays small, and internal notes, staff prices or unfinished text stay where they belong.

When the default shape does not fit, write a custom endpoint. A partner app may want one call that returns an event with its venue, speakers and ticket link, instead of four calls it has to stitch together. A route defined in a small plugin can return exactly that. Give it its own permission check, validate every parameter and put a version in the address, so the format can change later without breaking the apps already using it.

Writing through the API needs authentication. For a server that pushes content into WordPress, application passwords are built into core and can be revoked one at a time. Give that account the lowest role that does the job. An integration that only creates draft posts has no use for administrator rights.

Performance catches teams out. Each API request loads WordPress in full, and page caching often skips API responses. An app that fetches the whole post list on every screen can put more load on the server than the website itself. Paginate. Ask only for the fields that are needed. Cache responses on the consuming side or at the edge.

Changes on the website can now break things elsewhere. Renaming a field, deleting a category or swapping a plugin can alter a response that an app depends on. Keep a short document of which systems read which endpoints. Add those endpoints to the checks that run before every release.

Sometimes the right answer is a feed rather than an API. RSS still suits plenty of syndication jobs. A nightly export file is simpler for a system that needs one snapshot a day. Reach for the API when the other side needs fresh data on demand, and plan it as a product with users of its own.