hr.invalid_payment_method

HTTP 400   type: validation_error   param: payment_method

{
  "error": {
    "type": "validation_error",
    "code": "hr.invalid_payment_method",
    "message": "Payment method \"T\" (bank transfer) is not valid for an unattended sale. Use \"G\" for cash, \"K\" for card, or \"O\" when more than one method was used. Send sale_type \"attended\" if this receipt was issued by an operator.",
    "param": "payment_method",
    "upstream": null,
    "doc_url": "https://docs.fiskhub.com/errors/hr.invalid_payment_method"
  }
}

What happened

payment_method is not valid for the kind of receipt you are sending. Which set applies depends on sale_type:

Value	Croatian	Meaning	Unattended (§2.2.1)	Attended (§2.1.1)
G	gotovina	Cash	yes	yes
K	kartica	Card	yes	yes
O	ostalo	Other, including a sale split across methods	yes	yes
T	transakcijski račun	Bank transfer	no	yes

FiskHub checks this locally, before sending.

There is a second way to reach this code on an attended receipt: restrictive error 181, which forbids payment_method: "T" together with a recipient_oib. See below.

Should you retry?

Not unchanged. The set is fixed for the message type you chose.

The fix

Send G, K or O, uppercase — or T with sale_type: "attended" if a person really did issue this receipt.

{ "payment_method": "K" }

Common causes:

Sent	Problem
"T" on an unattended sale	Bank transfer. Valid on an ordinary receipt, not at a self-service device.
"T" with recipient_oib	Restrictive error 181 — see below. Drop one of the two.
"C"	Cheque. Removed from the specification on 1 September 2025.
"k"	Lowercase. Send uppercase.
"CARD", "cash"	A word rather than the code.
"G,K"	Two methods. Send O for a mixed payment.

Why T is refused on an unattended sale

T (transakcijski račun — bank transfer) belongs to the ordinary receipt, issued to a named recipient. An unattended sale has no recipient OIB in its message at all — there is no cashier and no named buyer — so a bank transfer has nothing to be reconciled against.

The same reasoning removes ParagonBrRac and OibPrimateljaRacuna from that message type. The unattended schema is the ordinary receipt schema minus the fields that only make sense with a person behind the counter.

If a person did issue this receipt, that is what sale_type: "attended" is for — see attended receipts. It is a different message, not a looser one.

Restrictive error 181 — T with a recipient OIB

On an attended receipt both T and recipient_oib are individually valid, and together they are not:

{
  "error": {
    "type": "validation_error",
    "code": "hr.invalid_payment_method",
    "message": "A recipient OIB cannot be sent with payment method \"T\" (bank transfer). The recipient OIB is only for B2B receipts settled in cash or by card — either drop it, or send \"G\" or \"K\".",
    "param": "payment_method",
    "upstream": { "code": "181", "message": "Ako se šalje OIB primatelja računa onda način plaćanja ne može biti T." },
    "doc_url": "https://docs.fiskhub.com/errors/hr.invalid_payment_method"
  }
}

The specification states it from both ends: the recipient OIB is delivered only for B2B transactions paid in cash or by card, and the payment-method row adds that a receipt carrying a recipient OIB cannot be paid by transfer. Sent together, the Tax Administration rejects the message as s013. FiskHub catches it first so that you get a sentence naming which of the two to drop rather than a Croatian error string.

Drop recipient_oib, or send G or K.

Mixed payments

A sale settled partly in cash and partly by card is O, not two entries and not two invoices. There is one sale, one receipt, one fiscal record.

{
  "total": "12.30",
  "payment_method": "O"
}

The breakdown between methods is your own record, not part of the fiscal message.