Card terminals in Lübeck, Germany

Match the terminal to the point of payment

A fixed counter gives staff a consistent place to check the basket, amount and payment result. Table service needs a way to identify the right bill away from the till. Mobile selling adds questions about coverage, power and what staff should do when they cannot confirm a result.

For a Lübeck merchant, test the intended payment locations rather than assuming one connection will work throughout the premises or at an outside trading location. Ask which connectivity options the proposed terminal supports and what happens if the connection drops. Device capabilities and availability in Germany must be confirmed with the team.

Separate a sale mistake from a payment mistake

An incorrect basket and an uncertain payment result need different responses. If the amount is wrong before payment starts, correct the sale first. If payment has already been attempted, establish its status before changing the order or starting another attempt.

Software partners should define how staff find the corresponding transaction, what each displayed status means and which record to check when screens disagree. Changing an order does not, by itself, establish that a payment has been reversed. Confirm supported cancellation and refund processes rather than assuming they are available through every device or connection.

• Pause further payment attempts while the result is unclear.
• Match the amount, time and available transaction reference.
• Follow the confirmed correction process or escalate with those details.

Worked example: a table payment loses its connection

Hypothetical example: a restaurant in Lübeck uses a software partner’s POS and a proposed portable terminal. A customer attempts to pay a €48 bill, but the connection drops before the waiter sees a clear result. The POS still shows the table as unpaid. That alone is not a safe reason to request another payment.

The waiter keeps the bill identifiable and asks the responsible colleague to check the payment record through the agreed route. If payment is confirmed, they follow the documented process for reconciling the order. If it is confirmed unsuccessful, they can offer another attempt. If it remains uncertain, they explain the uncertainty to the customer and escalate rather than guessing.

Make settlement questions part of the software discussion

A successful customer payment and money reaching the merchant’s account are separate events. Before rollout, ask about settlement timing, reporting, processing charges and how corrections appear in the records. Confirm the applicable German-market terms; do not carry assumptions over from another country.

NeroConnect is for connecting software and POS providers and their merchants to payment services. Discuss the proposed workflow with the team, including supported devices, integrations and how transaction references can be used during support. Availability and commercial terms need confirmation; a planned workflow is not evidence of a supported integration.

Test the recovery path before staff need it

Agree a controlled test plan with the provider covering a normal sale, an uncertain result and a supported correction. Use the tests to establish who can investigate, who can authorise corrections and what staff should tell customers while a payment is being checked.

An observable success check is that a staff member can trace the test sale to its payment result and explain any correction without creating an unexplained second payment. Your next action is to send the team your payment locations, POS details and one realistic error scenario, then request confirmation of the supported workflow.