Integration Review

anybill actively accompanies your POS integration. During development and prior to go-live, we review the implementation together with your team to ensure a reliable integration — benefiting you, your merchants, and anybill alike.

The following is a typical list of things we check before a POS integration goes into production. Each point names the question, what we expect to see, and where the underlying documentation lives. You can use it as a self-check before contacting us. The fundamentals are covered in Architecture and Data Flow and the API Reference.

How the review works

• When: Once the integration runs end to end against the Staging environment. Do not wait for the last feature — open questions are cheaper to resolve early.
• Who: Your tech contact at anybill, or dev@anybill.de if you do not have one yet.
• What to prepare:
  • A staging store with the merchant's master data (see Store master data).
  • One example receipt per receipt type the till can produce: standard sale, discount on a single item, discount on the whole receipt, return, cancellation, foreign currency payment, fiscal unit unavailable, and a receipt for a known customer. Send them to staging and share the billIds.
  • Screenshots or photos of the customer display and the cashier display for each of the cases in Customer and Cashier Display.
• Outcome: We walk through the list below with you, note open points, and confirm when the integration is cleared for production. Production credentials differ from staging and are handed out per merchant after the review.

Authentication

See Authentication. The POS SDK (C# only) handles this section for you.

• Where does the access token live, and how often is a new one requested? Expected: the token is cached and renewed with the refresh token before expires_in runs out, not requested per receipt.
• What happens if the token expires mid-shift? Expected: a single transparent re-authentication, no cashier interaction.
• Are the requested scopes sufficient for every endpoint in use? Store and loyalty endpoints need more than vendor/bill.
• Can a merchant be pointed at different credentials and a different environment without shipping a new POS release? Base URL and credentials differ between Staging and Production.

Resilience and error handling

See the Retry Policy Guidelines.

• Which status codes are retried, how long is the wait between attempts, and when do retries stop? Expected: 5xx (including 504, which anybill uses when a receipt could not be stored in time) and network errors are retried with exponential backoff and jitter, 3 to 5 attempts; a 401 triggers one token refresh and a single resend; 400, 403, 404 and 409 are never retried. See the status codes of POST /v3/bill.
• If a retry means the same receipt arrives twice, what happens? Expected: the receipt ID is registered in advance via /v3/bill/url and sent with the receipt, so a retry reuses the same ID and a duplicate is answered with HTTP 409 Conflict (Bill with id … already exists), which the POS treats as delivered. The same applies to the self-generated receipt ID feature, which has to be enabled per merchant.
• Are error responses logged including the traceId from the response body? Without it we cannot trace a failed request on our side.
• Does the receipt queue survive a restart of the till, and is there an upper bound on how long receipts are queued?
• If the API is unreachable, does the cashier see a prompt and an alternative? Customer and Cashier Display describes this as Case 4.

Store master data

See Store Endpoints.

• Are stores set up by hand once, or synced from existing master data?
• Do the store identifiers stay the same when a store is renamed or relocated? Only the address fields are schema-required, so a store can be created without an identifier of your own — we recommend always setting one.
• If two tills in the same store both sync, how does that result in one store rather than two? The search endpoint exists for exactly the case where tills cannot see each other.
• Does every store carry an external identifier that matches what the merchant uses internally? It is also included in the receipt notification webhook as externalStoreId.

Receipt content

See Bill Data Model, Bill Examples and the Print Buffer Format Guide.

• Compared with a printed receipt, what is missing from the digital one? Footer texts, legal notices, coupons and loyalty card numbers are common gaps.
• Is the serial number of the cash register sent, and is the receipt number of the till set in head? The receipt number is what the merchant uses to reconcile, and it is forwarded as receiptNr in the webhook.
• Does fullAmountInclVat match the sum of the lines and the sum of the paymentTypes? Is every vatAmount unique by percentage, both per line and on the receipt?
• Is a discount on the whole receipt sent as a discount line with negative values, separate from a price reduction on a single item? See Discounts.
• Does every discount carry a unique id, and does each vatAmount in the anybill extension have a matching one in the default line?
• Which quantity measure is sent for goods sold by weight or volume, and for an open product group?
• Which payment types does the till produce, and how is each one mapped? Several values are deprecated, and CardPayment replaces the individual card brands.
• For card payments, is the terminal receipt sent in additionalReceipts? See Terminal customer receipt.
• Where a payment is made in a foreign currency, are foreignAmount and foreignCurrency always sent as a pair?
• In which countries does the till operate, and which fiscalization type is sent for each? Tse applies to Germany; Rksv, BoiTva, TBai and others are described on the Fiscalization page.
• What is sent when the fiscal unit is unavailable? The fiscalization object can be omitted only with failure set to true in the security extension, or with required set to false for countries without a fiscalization obligation. See Which case applies?.
• If the print buffer is used, has the merchant-specific configuration on the anybill side been set up? See the note in the Print Buffer Format Guide.

Customer assignment

See Bill Endpoints.

• Which identifier is sent for a known customer, and where does it come from at the till? The userId and loyaltyCardBarcode fields are deprecated; use userIdentification.externalId.
• Does the integration handle both response types? An externalId that cannot be matched returns a url response rather than an error.
• Is transparent user creation enabled for this merchant? Without it, an identifier unknown to anybill will not create a user automatically.
• If a customer identifies themselves after the receipt was created, can it still be assigned?
• With loyalty in play, in what order do card scan, transaction and receipt submission happen, and what does the till do if the provider does not respond in time? See Loyalty Endpoints and the loyalty webhook.

Customer display and paper fallback

See Customer and Cashier Display and Legal Requirements at the POS.

• Is the QR code shown before or after payment? Both are supported, but the pre-payment case requires the receipt ID to be registered via /v3/bill/url and the receipt page updates once the receipt is sent.
• Is the url from the response rendered into the QR code unchanged?
• Does the cashier get a prompt to inform the customer, and does a known customer see a confirmation instead of a QR code (Case 3)?
• Are the logo and "powered by" assets from the POS Resource Package used?
• If a paper receipt is printed as well, is the printed timestamp set via POST /v3/bill/{billId}/printed?
• If there is no customer display, is the QR code printed on the paper receipt?

Cancellations and returns

• Is cancellation implemented, and is the difference between the 204 and 404 responses handled?
• After a cancellation at the till, is a corrected receipt sent as a new receipt?
• How is a return represented? Expected: a new receipt whose returned line references the original via lineReturnReference, with negative amounts. See Returning a line item.

Worth asking the merchant

These concern the merchant rather than the integration itself.

• Is there a customer display at the checkout, or does the QR code need to be printed?
• Is there a store list with stable internal identifiers, plus a logo and footer texts for the receipt?
• Is the data processing agreement with anybill in place? Your anybill contact can confirm this.
• Does a loyalty or CRM system need the receipt data, and is it expecting a webhook?
• Should receipts appear in the merchant's own app? This is a separate integration, covered in Frontend SDKs.