Troubleshooting

overview this guide provides step by step diagnostic procedures for identifying and resolving integration issues follow the standard diagnostic flow first, then refer to the specific playbooks for common failure scenarios standard diagnostic flow when any workflow fails — linking, subsidy card validation, trip, or payment — use this flow before escalating to cabfare support step 1 — identify the failing step determine exactly which step in the workflow is failing driver login device link request trip start subsidy card validation trip end and subsidy processing balance payment job done and shift end step 2 — check the last request and response log and inspect the full http request and response for the failing call url and method headers — are x api key and x api secret present and correct? request body — is it valid json with all required fields? http status code response body — inspect the detail array for field level errors never log your full x api secret value redact secrets in all logs and support tickets step 3 — cross check identifiers for the failing request verify driverid matches the value used during login on both devices vehicleplate is present and consistent across both devices taximeterid or terminalid is stable and consistent for the hardware tripid is the correct value for the current hire transactionid is unique and correct for the payment attempt inconsistent identifiers are the most common cause of 404 not found and linking failures step 4 — reproduce with a minimal payload use curl or postman with known good test data from the sandbox to reproduce the issue compare the failing request against the working test to identify the discrepancy curl i x post https //dcp sandbox nbggroup com au/api/v0 5 0/meter/driver/login \\ h "content type application/json" \\ h "x api key your sandbox key" \\ h "x api secret your sandbox secret" \\ d '{ "taximeterid" "tm100", "driverid" "999998", "vehicleplate" "m1000" }' step 5 — check connectivity if all requests are failing verify basic connectivity to the api curl i https //dcp sandbox nbggroup com au/api/v0 5 0/ping expect 200 ok with body {"response" "pong"} if this fails check your network, firewall, and tls configuration what to capture in your logs for reliable self diagnosis and efficient support escalation, log the following for every api call timestamp in utc endpoint and http method http status code returned taximeterid or terminalid driverid vehicleplate tripid where applicable transactionid where applicable any status , error , and detail fields from error responses for trip end and payment calls, the monetary values submitted and the values returned never log full card numbers or pci sensitive data for subsidy card numbers log only the last 4 digits where necessary troubleshooting playbooks playbook 1 — driver cannot start a subsidy scheme trip confirm driver is logged in on the taxi meter — post /meter/driver/login returned 200 ok confirm driver is logged in on the payment terminal — post /terminal/driver/login returned 200 ok check mptpdriverdata mptpstatus in both login responses — if mptp driver invalid on either device, subsidy scheme mode must be disabled confirm the payment terminal sent post /terminal/link/request and received a success response via post /link/response poll post /meter/driver/poll until loginstatus true and linkstatus true if link never becomes true, verify your post /link/response event handler is implemented and reachable once linked, confirm the taxi meter calls post /meter/trip/start and handles both 204 (subsidy scheme valid) and 202 (subsidy scheme invalid) responses correctly playbook 2 — manual subsidy card entry keeps failing verify the driver ui only accepts 9 digits and instructs the driver to omit the card number prefix call post /meter/mptp/validate with the 9 digit number in the mptpnumbers array for each item in the response array check mptpstatus — if invalid or expired display a clear error to the driver if the api returns 403 forbidden , the driver or vehicle is not authorised for subsidy scheme trips — contact cabfare support playbook 3 — payment not settling correctly confirm post /terminal/payment/complete is being called for every payment attempt — approved and declined verify all required fields are present terminalid , driverid , transactionid , paymentstatus confirm paymentstatus correctly reflects the outcome — an incorrect status may cause the backend to treat the transaction as unpaid match transactionid to the corresponding tripid in your internal logs to trace the full payment flow if the payment was approved on the terminal but not reflected in cabfare connect, the driver can manually mark the payment as successful on the taxi meter and continue contacting cabfare support when escalating to cabfare support include the following information to ensure fast resolution environment details sandbox or production api version (e g v0 5 0 ) affected components taxi meter provider name and software version payment terminal provider name and version problem description what the driver or operator attempted and what happened whether the issue is reproducible or intermittent approximate time and date of occurrence in utc technical artefacts http logs of the failing requests and responses — status code, response body, and relevant headers taximeterid or terminalid , driverid , vehicleplate , tripid , transactionid any ui screenshots or error messages shown to the driver contact support\@cabfare com mailto\ support\@cabfare com