1. Management of Car State Change
1.1 Realtime Change
There are three types of car state in UFPP: (1) car without linking. (2) car linked without frictionless payment. (3) car linked with frictionless payment. When car state changes, UFPP will synchronize the corresponding car state with parking lot system.
When a parking lot receives car state change request, it should update the car state and make the following judgements:
1) If the car is a newly added car, system should judge whether the car has entered the parking lot. If the car has already entered the parking lot, the parking lot should push the information of car entrance to UFPP.
2) If the car information has already been stored, the parking lot should update the car state.
▪ Major interface of this stage: CAR_SIGN_STATUS_INFORM
1.2 Stock Car Information Synchronization
After a parking lot launches the system, it can obtain stock user data before a certain date through the interface of stock car information synchronization.
To avoid car state change during the synchronization, when the parking lot system synchronizes in batch the car state, the system will chronologically save the latest car state if the car has been synchronized into parking lot system.
▪ Major interface of this stage: STOCK_CARS_REQUEST
2. Pushing Information of Car Entrance and Exit
Pushing information of car entrance and exit can be divided into pushing information of car entrance, pushing information of car exit:
1)Pushing information of car entrance
When a car enters the parking lot, the parking lot system will judge whether the car is linked through UFPP according to the synchronized car in UFPP. If it is a synchronously linked car of UFPP, relative car entrance information shall be pushed to UFPP to display the car entrance.
When UFPP has synchronized the car information with parking lot system, the parking lot shall define whether it is a newly added car. If it is newly added, the parking lot system shall identify whether it has entered the parking lot. If the car has already entered the parking lot, system shall prompt relative entrance information to UFPP to display the car entrance. (user adds the car information during parking)
2)Pushing information of car exit
When a car exits the parking lot, parking lot system will judge whether the car is linked through UFPP according to synchronized car in UFPP. If it is a synchronously linked car of UFPP, relative car exit information shall be pushed to UFPP. After UFPP received car exit information, car entrance information will not be displayed on the front page.
3. Payment on Initiative
3.1 Parking Fee Inquiry
Previous Procedure: Car information synchronization
After receiving the car entrance information, UFPP records the information of the parking lot that the car entered, allows user to enter the parking lot and inquire parking fee.
Interface description:
▪ After user drives a car and enters the parking lot, user can inquire parking fee information through this interface.
▪ User can view his/her debt information at any time and initiate payment on initiative.
▪ If user has partly paid the fee, the amount of rest fee to be paid shall be returned from this interface, i.e. it supports multiple payment on initiative during one time of car entrance and exit.
▪ Major interface of this stage: ORDER_UNPAY_INQUIRY
3.2 Payment
Previous Procedure: Parking fee inquiry
User initiates payment on initiative through this process.
If user overdues the limit time of free parking, he/she shall re-inquire the parking fee and initiate payment on initiative again according to the remaining fee amount to be paid.
▪ Major interface of this stage: PAY_RESULT_INFORM
▪ User initiates payment through UFPP function for payment on initiative. After the deduction is completed, UFPP synchronizes the paid bill with the parking lot. After receiving the bill, the parking lot should return the result of billing processing and synchronously respond to UFPP. UFPP displays the payment result to user.
▪ Other circumstances:
1)After sending synchronization of paid bill, if UFPP does not receive the response from parking lot system within network timeout limit, UFPP will repeat the bill synchronization message for 3 times with one minute in between. At this time the bill detail will display “processing the payment”.
2)After UFPP sends synchronization of paid bill, if the parking system returns payment failure with specific reason (such as user has paid in other ways, other situation that leads to non-existence of bill), UFPP will automatically initiate cancellation/ refund. User finds the payment failure on the page of order details with specific reason displayed.
4 Frictionless Payment
4.1 Car Entrance Stage
When a car enters the parking lot, parking lot system shall inquire whether this car has enabled frictionless payment function. If it is enabled, the frictionless payment will be the priority for payment when car exits the parking lot.
Identify car license plate and judge the frictionless payment state:
▪ Major interface of this stage: CAR_SIGN_STATUS_INQUIRY, NOTICE_ENTRANCE
▪ If the parking lot system has already recorded the car enabled frictionless payment at its entrance, it shall inquire car state on UFPP to ensure whether the car state changes. Meanwhile, the parking lot system should push the relative car entrance information to UFPP if the parking lot identifies the car is linked to UFPP.
▪ When user enables or disables frictionless payment function during the parking, UFPP will synchronize the state with parking lot in real time.
▪ Please ensure to push the car entrance information to UFPP. If user’s signing state changes during the parking, UnionPay will push message to the parking lot first to update the state.
4.2 Car Exit Stage
Parking lot shall inquire whether there is fee to be paid first. If user has launched payment on initiative, parking lot shall judge whether there is remaining fee to be paid. If has, the parking lot system will push the billing to UFPP for frictionless payment.
Frictionless payment in parking lot has two scenarios:
1)Bar-lifting before payment: To avoid fund deficit due to the failure of user state synchronization, before bar lifting, the parking lot system should inquire car state on UFPP, receive the response of car state from UFPP (withholding or not). If the car state is withholding, parking lot will push bill to UFPP for frictionless payment after bar-lifting; If the car state is not withholding, the system shall update user’s state and instruct user to complete payment in other ways before bar-lifting.
▪ Major interface of this stage: CAR_SIGN_STATUS_INQUIRY, PAY_BILL, PAY_RESULT_INFORM, PAY_STATUS_INQUIRY, NOTICE_EXIT
▪ Considering the bar-lifting before payment model has certain risk, it is recommended that parking lot system automatically changes to the model of bar-lifting after payment when the fee payable is over 300 RMB.
▪ After the parking lot pushes bill for frictionless payment, if parking lot receives synchronous response but does not receive asynchronous payment result within 10 seconds, it will initiate order payment status inquiry. If parking lot still does not receive response for order payment state inquiry or the returned response is “processing the payment”, the parking lot will keep sending order payment state inquiry every 1 minute. The parking lot should repeat the process for most 3 times if the payment state is unclear, until receiving the clear order state from UFPP.
2)Bar-lifting after payment: Parking lot pushes bill to UFPP for frictionless payment according to the stored frictionless payment state of cars, and then lifts the bar after receiving payment success notification from UFPP.
▪ Major interface of this stage: PAY_BILL, PAY_RESULT_INFORM, PAY_STATUS_INQUIRY, OTICE_EXIT.
▪ After the parking lot pushes bill for frictionless payment, if parking lot receives synchronous response but does not receive asynchronous response result within 10 seconds, it will initiate order payment status inquiry every 2 seconds for at least 5 times. The following circumstances may occur:
(1)If the payment status is “success”, the parking lot will lift the bar and allow the exit. If the payment status is “failure”, it will turn to payment offline.
(2)If the payment status is “processing the payment”, the parking lot system will directly turn to payment offline and initiate cancellation/refund when receiving confirmed payment status and the result is “success”.
(3)If the parking lot does not receive response, the parking lot will directly turn to payment offline and initiate transaction result inquiry on regular basis. It is recommended that the inquiry will be no less than 3 times with 1 minute in between. After receiving the payment result, the parking lot initiates cancellation/refund if the result is “success”.
5. Transaction Cancellation/Refund
Scenario 1: In the model of bar-lifting after payment, before a car exits the parking lot, parking lot initiates frictionless payment. If it does not receive payment response within 10 seconds, parking lot sends payment status inquiry to UFPP and repeats sending the inquiry every 2 seconds. If the payment result does not return after 5 times of inquiry, the frictionless payment can be regarded as failure, and user can pay parking fee offline and exit the parking lot. Then the parking lot initiates cancellation/refund after receiving confirmed payment status and the result is “success” from UFPP.
Scenario 2: In the model of payment on initiative, after user completes the payment on initiative, UFPP pushes payment result to parking lot. If the parking lot finds that user has complete the payment in other ways, it responds to UFPP the failure of payment on initiative and then UFPP proactively initiates transaction cancellation/refund.
▪ Major interface of this stage: PAY_STATUS_INQUIRY, PAY_RESULT_INFORM, REFUND_BILL, REFUND_STATUS_INFORM, REFUND_STATUS_INQUIRY.
▪ Parking lot system shall initiate transaction cancellation/refund when receiving confirmed payment status and the result is “success”.
6. Others
6.1 Parking space inquiry / Busyness of parking lot
User can inquire the parking space through this function. Channel page will display the parking space according to the parking state returned from parking lot. For example, parking lot can return the specific number of parking spaces, such as “12”, “0”, etc., and the busyness of parking lot, such as “Free” or “Busy”.
▪ Major interface of this stage: PARKING_INQUIRY.
6.2 Health Check
To ensure the normal operation of interconnection between parking lot and UFPP, UFPP will invoke the health check API provided by parking lot system on a regular basis (every 5 seconds) to check whether the parking lot system is in action.
If UFPP finds parking lot cannot provide service temporarily (e.g. system upgrade or other situation), when UFPP need to synchronously update user’s state to parking lot system, UFPP will record failure and synchronize the failed record after parking lot system operates properly.
▪ Major interface of this stage: HEALTH_CHECK.
Kindly Reminder