Open API >Payment >Frictionless Parking
Frictionless Parking
Payment Developer Merchant Mobile Payment
Provide users with card binding service and parking lot merchants with trading interfaces.
API Introduction
API Introduction
What is it?

UnionPay Frictionless Payment Platform (UFPP) provides non-stop payment user experience with automatic deduction from a bank card through binding the UnionPay card with a car plate number under the scenario of car parking or highway toll fee payment. When a car passes through the barrier gate, the information of the car can be read through automatic car license plate recognition technology and the parking fee will be culculated based on parking fee rules at car park back system. The car park will initiate a  payment rqeuest to UFPP, then the parking fee will be deducted automatically.

Key features

Security

Security is a basic requirement for payments. UPI Frictionless Parking solution adopts payment tokenization to guarantee payment security. 

Frictionless

Parking fee can be paid in a frictionless way.

Swiftness

UPI Frictionless Parking solution reduces queueing time and optimize the parking traffic

Openness

UPI Frictionless Parking solution provides open solution. The service can be enrolled from any APP that supports UPI’s Frictionless Payment, and transaction can be initiated from any car park that supports UPI’s Frictionless Parking. 


When to Use it?

Applicable to mobile App providers and car park merchants that want to integrate UPI   Frictionless Parking function and provide frictionless parking payment service to their customers.

Who use it?
Acquirer, Issuer, Software developer and Merchant.
Where to Use it?
This API is available globally except for mainland China
Things to Know

1.UnionPay frictionless payment supports the credit card, debit card and pre-paid card which is issued outside Mainland of China, and credit card issued inside Mainland of China.


2.The priceing will adopt the UnionPay online payment pricing stadard. If there is a special price for car park MCC, the special price will previal.


3.Dispute resolution will follow current dispute resolution process for UnionPay online products.


4.Risk control

a)If the frictionless payment fails, the car information will be added into the black-list. The car can only be removed from the black-list after the user proactively pays the fee. Otherwise, frictionless payment will be not available next time when the user enters the UnionPay frictionless payment car park.

b)For users who fail for the deduction, UFPP will prompt SMS or APP alert to remind the cardholder to deal with the failed payment.

c)Car park should retain CCTV videos and other information to record the using logs.


5.Bar-lifting mode of Car Exit

The following two types of bar-lifting models are supported by UnionPay when cars exit the car park:

1)Bar-lifting before payment

In this mode, if the frictionless payment fails, in fact, user has already enjoyed the parking service but failed to make the payment. In this case, the car information will be added into black-list. Once got blacklisted, user cannot enjoy frimctionless payment anymore untill he/she pays the parking fees proactively.

2)Bar-lifting after payment

In this mode, if the frictionless payment fails, user has to pay the parking fee offline before leaving, then UnionPay will not add the car information into black-list.


Flow Chart
Flow Chart

无感停车-业务流程图.jpg

API Document
API Document
Response Code Reference
Response Code Reference
Response code Description
00 Approved
01 Please refer to the card issuer
03 Invalid merchant
04 Pending. Transaction result is unknown. Please check later
05 Cardholder verification fails
12 Invalid transaction
13 Invalid amount
14 Invalid card number
15 No such issuer
21 Card status error
25 Unable to locate the original transaction
30 Message format error
34 Fraud card
40 The transaction is not supported by the issuer
41 Lost card
43 Stolen card
51 Insufficient balance
54 Expired card
57 Transaction not permitted to cardholder
61 Exceeds approval amount limit
62 Restricted transaction
90 The system is in cut-off
91 Issuer system error
92 Network error
94 Duplicated transaction
96 UnionPay system error
98 Timeout
A0 Signature verification fails
Sequence Chart
Sequence Chart

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.

时序图1.png

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.

时序图2.png

▪ 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.

时序图3.png

  ▪ 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.

时序图4.png

▪ 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.

时序图5.png

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.

时序图6.png

▪ 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.

时序图7.png

▪ 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.

时序图8.png

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”.

时序图9.png

▪ 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.

时序图10.png

▪ Major interface of this stage: HEALTH_CHECK.


Steps to Launch
Steps to Launch

For Merchant (Car Park):

Car park is responsible for the car license plate identification, billing and gateway management for entrance and exit of the parking lot.

The merchant shall fill in the UPI Frictionless Parking Service Application Form and E-commerce and In-app Acquiring Program (Direct Mode)_Frictionless Parking Form.


For Acquirers:

Acquirer is responsible for the settlement with parking lot. Currently, since the frictionless payment transaction goes through UPOP channel, the acquirers shall support single message file.

The frictionless payment transaction to be settled will count together with other genearl transactions as “General Acquirer’s Transaction Audit Trailer”, i.e. ACOM/ACOMN Trailer. The primary key of each record in the file is the first 4 fields of the record, including Acquirer Insitution Identification Number, Forwarding Institution Indentification Number, System Trace Audit Number, Transaction Date and Time. These 4 fields are in conformity with Field 32, Field 33, Field 11 and Field 7 in the 8583 transaction message.

In Settlement Summary Report, the frictionless payment transaction and other internet transaction will be displayed at “e-commerce” section.


  • Contact Us
  • If you have any further questions, please register and submit order in your user center.