“The card worked, but something went wrong” is difficult to investigate. A useful support file turns that message into a traceable sequence: the station involved, the rental reference, the payment outcome and the physical result. It helps a Slovak operator distinguish a reader question from a cabinet fault or a billing correction.
The file can be a simple controlled document linked to the operator’s existing support process. Its value comes from consistent evidence and a named owner, rather than the number of screenshots collected.
Establish the Slovak deployment boundary
Stripe currently describes Terminal in Slovakia as Private preview. Its country guidance specifies EUR and the appropriate Slovak account and reader Location, with WisePad 3 listed. Confirm preview access for the actual operator, local reader procurement and the proposed venue scenario with Stripe before ordering or opening. The operator buys and registers the reader through its own eligible local account.
The CoreCharge matched route uses its completed WisePad 3 integration with a native Android rental application and Terminal SDK inside the cabinet. The reader uses the agreed USB data and power connection; no separate merchant phone is required for the ordinary flow. Stripe handles payments into the operator’s own account, while CoreCharge connects orders, release, returns and rent calculation.
Open the file with a customer outcome
Give the case a reference, time opened and responsible person. Begin with one factual sentence such as “Customer reports no bank released after presenting a card.” Separate what the customer reports from what system records confirm. Avoid labelling an amount a completed charge before checking its actual status.
Record whether venue assistance was available. A proposed fully unattended placement needs its own reader-use confirmation; a support template does not establish that approval.
| Evidence group | Useful information | Who verifies it |
|---|---|---|
| Venue and equipment | Station code, cabinet serial and observed screen | Venue contact or service operator |
| Rental | Order reference, start time, release and return events | Authorised CoreCharge dashboard user |
| Payment | Transaction reference, amount, currency and current state | Authorised Stripe account user |
| Customer effect | No release, unusable unit, disputed duration or pending amount | Support owner after checking evidence |
| Resolution | Approved action, financial reference if applicable and follow-up | Person authorised for that action |
These are investigation fields, not a claim that every item is automatically combined in one native report. Agree available dashboard fields and the operator’s access permissions during onboarding.
Reconstruct a timeline before repeating a payment
Place the customer’s approximate time beside the recorded payment attempt and cabinet events. A successful authorisation without a confirmed release needs a different response from a completed rental with a confusing bank display. A missing return event needs device evidence as well as a customer statement.
Reconcile the original attempt before asking the customer to pay again or issuing another release command. Record uncertainty explicitly. If the team has not yet established the result, assign the next check and customer update rather than marking the case closed.
The end-to-end validation guide provides a useful event matrix. For post-return enquiries, use the distinction between authorisation release and refund before choosing a financial action.
Collect less sensitive material
Routine support should not request full payment-card numbers, PINs, bank passwords or Stripe account credentials. Crop unrelated transactions from evidence and redact sensitive details before sharing it with another team. References needed by authorised support are different from information suitable for a public customer message.
Keep integration secrets out of the file and cabinet application. Stripe’s key-management guidance recommends protected server-side storage and limited permissions. A request to investigate one order should not become a request for unrestricted account access.
Close the file with a checkable result
Record what changed, who approved it and which evidence confirms the outcome. A submitted refund request is not the same as a verified refund result. Retain unresolved technical follow-up separately if the immediate customer issue has been addressed.
Review CoreCharge reader-equipped stations or request a Slovakia support and handover template for your proposed venue team.
References and project scope
Technical references checked on 17 October 2026. The operating procedures above are planning guidance; hardware, account access and payment settings are confirmed for each deployment.