Two Czech payment gateways brought to the Odoo App Store

The problem

Odoo ships payment providers for the processors that dominate Western Europe and North America. In the Czech Republic those are not the processors anyone uses.

A Czech merchant selling through Odoo e-commerce has two realistic options — Pays.cz and Comgate — and at Odoo 18 the App Store had no working e-commerce module for either. Comgate in particular had no v18 e-commerce module at all. The practical consequence is that a Czech business either abandons Odoo's webshop or bolts on an external checkout and loses the order-to-invoice chain that made Odoo worth running.

What I built

TABSAP Pays.cz Connector — a full payment provider integrated into Odoo 18's checkout. It implements Pays.cz's secure redirect flow with HMAC-MD5 signature verification on the return leg, so a tampered callback cannot mark an unpaid order as paid. It handles CZK, EUR and USD, and localises into Czech, Slovak, English, Russian and Japanese. A post-init hook configures the payment method on install, so there is no manual provider setup step to get wrong.

Listed on the Odoo App Store →

TABSAP Comgate Connector — the same job for Comgate, the larger Central-European processor. Cards, bank transfers, Apple Pay and Google Pay across nine currencies, with full and partial refunds handled inside Odoo's own payment transaction flow rather than as a manual reconciliation step.

Refunds are where most gateway integrations quietly stop. Issuing one is easy; representing it correctly against the original transaction so the accounting stays right is not, and a partial refund is the case that exposes whether the integration was finished or merely demonstrated.

Outcome

Both connectors were verified end to end against live transactions — success, pending, cancel and partial-refund paths — not against sandbox responses alone. Pays.cz is published on the Odoo App Store. The Comgate module fills a gap that had left Odoo 18 without any e-commerce Comgate option.

Why it mattered

This is the same pattern as the DHL Freight work for the same client: the generic international module exists, looks correct, and does not survive contact with the local provider. The difference between the two situations is only which layer breaks — shipping or payment.

Building against the local API rather than the generic one is more work up front and it is the only version that holds up. A payment integration that fails on a real refund fails in front of a customer who has already been charged.