Card / IRIS payments¶

Under decision A.1155/2023, when a business's POS terminal is "locked" (interconnected), a card or IRIS charge can only be made with a provider signature. The certified e-invoicing provider gives the signature, the POS uses it to charge the customer, and then you complete the document.

Who needs this

Only businesses whose POS must be interconnected. AADE (the Greek tax authority) decides this per business and per terminal, and the provider cannot know it. That is why the skipSignature parameter exists.

Under AADE circular E.2044/2024, the cases outside interconnection include distance sales (e-shop), payments via payment link, and businesses with no obligation to use a fiscal cash register (ΦΗΜ) (e.g. POL.1002/2014, wholesale only). In those cases, send with skipSignature=true. For each customer's specific case, their accountant gives the final answer.

Two integrations¶

A card payment involves two separate integrations. The provider does not talk to the terminal.

Integration	What it does	API and sandbox
Application ↔ Provider (Novus)	Gives the provider signature and, after the charge, transmits the document to AADE (MARK).	Novus: this documentation
Application ↔ POS / NSP (e.g. Viva, Mellon, Cardlink, Worldline, Nexi, Euronet, EDPS)	Sends the amount and the token to the terminal, charges the card and returns the `transactionId`.	Your NSP

At the NSP you declare Novus Conceptus as your provider. AADE has two identifiers for us, provider_id 005 and license_id 105: test in the NSP's sandbox which one it accepts.

skipSignature: the switch¶

`SendInvoices?skipSignature=`	What happens with payment `type` 7 (card) or 8 (IRIS)
`true` (default)	The document is issued immediately (MARK, UID, AuthCode). No signature is returned. For a POS that is not locked.
`false`	The document is put on hold and does not go to AADE yet. A `providerSignature` is returned for the POS. For a locked POS.

If the document has no payment of type 7 or 8, skipSignature has no effect.

Flow 1: issue and pay together (checkout)¶

sequenceDiagram
    autonumber
    participant APP as Checkout / ERP
    participant NP as Novus Provider
    participant POS as POS / NSP (bank)
    participant AADE as AADE
    APP->>NP: SendInvoices?skipSignature=false<br/>paymentMethods: type 7, terminalId, posNspId
    NP-->>APP: providerSignature[].signatures[].token (+ data)
    APP->>POS: charge with the token
    POS-->>APP: transactionId, final paymentType (card or IRIS)
    APP->>NP: CompletionPosInvoices [ signatureToken, transactionId, paymentAmount, paymentType ]
    NP->>AADE: transmit document + payment
    NP-->>APP: MARK, UID, AuthCode, invoiceUrl

A signature is not an issued document

With skipSignature=false, in SendInvoices the Provider runs only its own checks and returns the signature. The document is transmitted to AADE only in CompletionPosInvoices, that is after the customer has paid. If AADE rejects it at that point (e.g. a wrong classification, VAT or totals), the document is not issued, while the card has been charged.

So, before you ask for a signature, you must be sure the document will pass:

In the sandbox, test the whole flow (signature and completion) for every combination of document type, VAT and classification that you will send with a card. In production, stick to those.
In your app, before the call, check what AADE rejects most often: totals and rounding (errors 207, 208, 312), classification combinations, VAT category and exemptions, the recipient's VAT number, a unique series and number (error 228).
For a document with anything unusual, issue first and charge afterwards with Flow 2.

If it happens anyway, the customer has paid for a document that was not issued. How that is settled (refund, new charge, re-issue) is an accounting matter: agree it in advance with your customer's accountant.

Step 1: send the document with skipSignature=false and, in the payment, terminalId and posNspId:

"paymentMethods": [ { "type": 7, "amount": 124.00, "terminalId": "TID00001", "posNspId": 1 } ]

Step 2: the response contains the signature:

"providerSignature": [
  {
    "invoiceUid": "5E1F953760F9496F5520A961DA3BE07B30ED07F8",
    "signatures": [
      {
        "token": "3045022100F0B3EAEAAC535A0C6549B42619C65895...",
        "data": "5E1F953760F9496F5520A961DA3BE07B30ED07F8;;20260924155441;10000;2400;12400;12400;TID00001",
        "createdDate": "2026-09-24T12:54:41Z",
        "expiryDate": "2026-09-25T12:54:41Z",
        "isExpired": false,
        "paymentBalance": 124,
        "issuerVatNumber": "123456789"
      }
    ]
  }
]

token: pass it as is to the NSP/bank API. It is already in the format the NSP expects (HEX or BASE64, based on posNspId). Do not convert it.
data: the data that was signed. Some NSPs require it together with the token.
Validity: 24 hours. For food service transactions (specialInvoiceCategory = 12) it is valid for 2 hours.

Step 3: charge on the POS. The customer can switch payment method (e.g. from card to IRIS). Keep the transactionId and the final payment type.

Step 4: complete the document:

POST /api/v1/Provider/CompletionPosInvoices

[
  {
    "signatureToken": "<providerSignature[0].signatures[0].token από το SendInvoices>",
    "transactionId": "123456788555",
    "paymentAmount": 124,
    "tipAmount": 0,
    "paymentType": 7
  }
]

Field	Required	Note
`signatureToken`	yes	The `token` from step 2.
`transactionId`	yes	From the POS/NSP.
`paymentAmount`	yes	> 0 and not greater than the signature's `paymentBalance`.
`tipAmount`	no	Tip.
`paymentType`	no	The final type from the POS: 7 or 8. If missing, 7 is assumed.

The response has the same format as SendInvoices, with MARK, UID, AuthCode and invoiceUrl.

Flow 2: paying an earlier document (on credit)¶

The document was issued earlier (e.g. type: 5, on credit) and is now paid by card.

POST /api/v1/Provider/AskSignatureForOldInvoice?terminalId=TID00001&posNspId=1. The body is just the MARK: 400001930000001. The response returns token, data, paymentBalance.
Charge on the POS with the token.
POST /api/v1/Provider/CompletionAskSignatureForOldInvoice?signatureToken=…&transactionId=…&paymentAmount=…&tipAmount=0&paymentType=7. The body is again just the MARK.

Details: Other endpoints.

Failed payment, cancellation, timeout¶

In Flow 1 (issue and pay together), until CompletionPosInvoices the document stays pending and has not been transmitted to AADE. If the charge on the POS does not go through, or the completion fails:

What happened on the POS	What you do
The card was declined or the transaction was cancelled, and the customer tries the card again	Charge again with the same token while it is valid (24 hours, 2 hours for food service). When it succeeds, call `CompletionPosInvoices`.
The customer finally pays another way (e.g. cash)	Resend the same document, with the same number, with the new payment method. Do not call `CompletionPosInvoices` for the unused signature.
Timeout: you don't know whether the charge went through	First check the transaction status on the POS / NSP. If it was charged, call `CompletionPosInvoices` with the `transactionId`. If not, follow the first two rows.
The charge succeeded, but `CompletionPosInvoices` returned an AADE error	The customer paid, the document was not issued. How it is settled is an accounting matter: follow what you have agreed with your customer's accountant. To avoid it, see the warning in Flow 1.

Never call CompletionPosInvoices without a successful charge: the completion transmits the document as paid by card or IRIS.

In Flow 2 the document has already been issued. If the charge does not go through, you don't call the completion and the document stays unpaid.

Testing¶

Novus does not provide a POS or a simulator. For the charge, use your NSP's sandbox or test terminal.
The provider sandbox returns a real signature, in the format the NSP of the posNspId expects (HEX or BASE64).
Without a terminal you can test the whole flow on the provider side: in the sandbox, CompletionPosInvoices also accepts a test transactionId. It is ready in Postman, folder 4 (4.1 and 4.2).
Card / IRIS payments are not certified. You declare them in the certification request.

Errors you will see¶

Message	What it means
`If one of the payment methods requires pos then the Terminal Id (tid) field is required.`	`terminalId` is missing with `skipSignature=false`.
`If one of the payment methods requires pos then the Pos Nsp Id fields is required.`	`posNspId` is missing.
`The transactionId field is required.`	Completion without `transactionId`.
`One ore more of the tokens is not verified.`	Wrong or tampered token.
`One ore more of the signature token balance is not enough.`	`paymentAmount` exceeds the remaining balance of the signature.
`The paymentType field only accepts values 7 or 8.`	Another type was sent in the completion.

Good to know¶

Each payment line with a signature costs 0.25 credits extra (Credits).
The paymentType requested in SendInvoices is not final. The final type is declared in the completion.
If you print your own document, print the transactionId and the signature used for each amount (printing rules).
In a future version, skipSignature will be removed and the signature will always be returned for types 7/8.

Special cases¶

Case	How to do it
Several invoices, one card charge	One 8.4 (POS Collection Receipt) for the total amount, with the MARKs of the invoices being paid in `invoiceHeader.multipleConnectedMarks`. One signature, one charge, one completion.
Deposit (e.g. a booking invoiced later)	When you take the deposit, issue an 8.4 with `skipSignature=false`. When the final document is issued, put the MARK of the 8.4 in `multipleConnectedMarks`.
Refund to the card	Issue the proper credit note (e.g. 11.4) with payment 7 or 8 and `skipSignature=false`, as for a sale. With the signature, the terminal performs the refund.
Mail order, instalments, pre-authorization	Same signature as a simple sale. The differences concern only how your application talks to the terminal.
Provider code at the NSP	AADE has two identifiers for Novus Conceptus: `provider_id` 005 and `license_id` 105. Each bank / NSP asks for one of the two in its own field (e.g. `aadeProviderId`). Test in the NSP's sandbox which one it accepts.
Viva: VAT 2400 in `data`	The VAT field in the signature's `data` is always `2400`, whatever the VAT rates. It does not affect the charge. Pass `token` and `data` exactly as you receive them.

POS receipts (8.4 / 8.5)¶

For businesses that collect or refund amounts via POS (e.g. on behalf of third parties, with thirdPartyCollection).

11.1 with card payment (for skipSignature=false)