Features & Usage

q7 how does cabfare connect remove the need for one to one integrations? instead of each taxi meter integrating separately with each payment terminal, both sides integrate once with cabfare connect cabfare connect then receives events from taxi meters — driver login, trip start and end, subsidy card validation requests, payment requests receives events from payment terminals — driver login, card reads, payment completions coordinates these events, applies subsidy scheme rules, and sends outcomes back to the relevant device this event driven broker model reduces development effort and maintenance, and allows fleets to mix different taxi meter and payment terminal providers without additional integration work q8 how is a subsidy scheme trip lifecycle handled between the taxi meter and payment terminal? the high level flow is trip start — taxi meter calls post /meter/trip/start with tripid , device, driver, and vehicle details subsidy card capture — payment terminal reads the card and calls post /terminal/mptp/validate , or taxi meter performs manual entry via post /meter/mptp/validate if the card cannot be read trip end and subsidy calculation — taxi meter calls post /meter/trip/end with fare details cabfare connect processes the subsidy and returns the subsidy amount and remaining passenger payable balance to both devices balance payment — taxi meter requests card payment from the payment terminal via post /meter/payment/request , or the driver accepts cash or another method directly job done — taxi meter calls post /meter/job/done to close the trip and trigger subsidy provider reporting refer to the workflows section for the full step by step for each stage q9 does cabfare connect support standard card payment trips without a subsidy? yes cabfare connect supports both standard card payment trips and subsidy integrated trips in a standard trip no subsidy card validation occurs the full fare calculated by the taxi meter is passed to the payment terminal as the balance amount the payment terminal processes the card payment and reports the outcome to cabfare connect post /meter/job/done closes the trip as normal q10 how are government subsidies and lifting fees handled? at trip end the taxi meter submits all fare and subsidy scheme details to cabfare connect via post /meter/trip/end cabfare connect validates member eligibility and driver and vehicle registration confirms subsidy and lifting fee rules per the subsidy provider returns the actual amounts paid per member plus overall totals returns issubsidycalculationmatching to indicate whether the taxi meter's calculation matches the backend the payment terminal then collects only the passenger payable balance if issubsidycalculationmatching returns false always use the cabfare connect returned values as the source of truth q11 how often should i poll for driver or link status? poll only on key events or when your ui needs to recover from a suspected state mismatch — for example after connectivity loss over polling increases load unnecessarily cabfare connect is event driven and your devices should rely on inbound event notifications for state updates during normal operation rather than continuous polling q12 what happens if the network goes down during a trip? maintain trip state locally on the device on reconnection use post /meter/driver/poll or post /terminal/driver/poll to verify current session state re send any missing events using the original tripid and transactionid do not generate new identifiers on retry retrying with the same identifiers is safe refer to the network resilience considerations page in core concepts for full guidance q13 can the driver or vehicle be changed during an active trip? this is not recommended best practice is to end the current trip, log out, and log back in with the new driverid or vehicleplate changing these identifiers mid trip risks data integrity issues in subsidy provider records q14 how does cabfare connect handle authentication for inbound events it sends to my system? all inbound requests from cabfare connect to your hosted endpoints include your x api key header your system must validate this header on receipt of every inbound event before processing it refer to the authentication and security page in core concepts for full details