Many finance teams want to steer customers toward cheaper-to-process payment methods — offering a small cash or bank-transfer discount to dodge card interchange fees, or a wallet-specific promotion to hit a partner target. Out of the box, Odoo has no concept of a discount conditioned on how the customer pays. Discounts live on pricelists, coupon programs or manual sale-order lines, all of which are decided long before the payment step. The result is manual line edits, spreadsheets of "if they pay cash, knock off 2%," and reconciliation headaches when the recorded discount and the actual tender disagree. Native account.payment and pos.payment carry no pricing logic, and pricelist rules key off product, quantity and partner — never payment.method.line or pos.payment.method.

We build a dedicated module that closes this gap. At its core is a configurable payment.method.discount model (models.Model) that maps each payment method — a Sales/Accounting account.payment.method.line or a pos.payment.method — to a discount rule: fixed amount or percentage, optional minimum order value, product/category eligibility, active date window and per-company scope. Fields are computed with @api.depends so the eligible discount recalculates whenever the payment selection, order amount or partner changes, and @api.constrains guards against nonsensical setups (negative percentages, overlapping windows, discounts exceeding the order total). Access is locked down with ir.model.access.csv plus record rules that respect company_id for multi-company databases, so a subsidiary's payment-discount table never leaks into another company.

On the Point of Sale side, the discount is evaluated the moment a payment line is added: an OWL PaymentScreen extension recalculates the order total live so the cashier and customer both see the corrected figure before tender, and the applied rule is written back as a distinct discount line (never a silent price edit) for a clean audit trail. In Sales and Accounting, the module hooks payment registration and the confirmation flow so that selecting a bank-transfer or cash method proposes the mapped discount, records it against the invoice or sale order, and keeps the journal entry balanced. Everything surfaces in a QWeb report and a filterable list/pivot view so finance can see exactly how much margin each method costs, and an optional automated action can flag orders where the tendered method did not match the discount that was granted.

Because this is built to order, we start from your real payment-method configuration and workflow rather than a generic template. After a short scoping call we confirm the exact rule matrix, POS-versus-back-office behavior, rounding and tax treatment, then build against your target release — we support Odoo 17.0, 18.0 and 19.0, and account for Community-versus-Enterprise differences (Enterprise ships extra POS payment terminals and accounting flows the rules must respect). Typical delivery is 2–4 weeks from confirmed scope, on a staging database first. Pricing starts from $249 (indicative, single-company base scope); multi-company rule tables, POS-terminal integrations, complex tax/rounding localization, and migration of historical discount data increase the quoted scope. You get a fixed quote after the scoping call — no surprise line items.