CN110766394B

CN110766394B - Credit-based ride payment method, device, electronic device and storage medium

Info

Publication number: CN110766394B
Application number: CN201911001496.3A
Authority: CN
Inventors: 刘家凯
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2019-10-21
Filing date: 2019-10-21
Publication date: 2025-01-03
Anticipated expiration: 2039-10-21
Also published as: CN110766394A

Abstract

The embodiment of the invention provides a riding payment method, a riding payment device, electronic equipment and a storage medium based on credit, wherein the riding payment method comprises the steps of responding to an opening instruction of a virtual riding card, presenting a payment authorization key for authorizing a payment mode corresponding to the virtual riding card, responding to an authorization instruction triggered based on the payment authorization key, acquiring the credit of a target user associated with the virtual riding card, distributing corresponding payment amount for the virtual riding card based on the credit of the target user, responding to a first payment order sent through near field communication connection, deducting the order amount corresponding to the first payment order from the payment amount, and sending a second payment order to a payment end corresponding to the payment mode based on the order amount so as to deduct the order amount from a payment account of the associated target user based on the second payment order.

Description

Riding payment method and device based on credibility, electronic equipment and storage medium

Technical Field

The present invention relates to communication technologies and blockchain technologies, and in particular, to a riding payment method and apparatus based on confidence, an electronic device, and a storage medium.

Background

With the development of internet technology, the user takes bus (such as buses and subways) and goes out and mostly adopts the physical bus card to pay the bus, and the user finishes the bus payment by swiping the card on the card swiping equipment, so that the physical bus card is greatly convenient for the user to go out.

In the related art, the balance of the riding fee is required to be paid sufficiently before the riding card is used, the user needs to recharge the riding card in advance, the user needs to go to a special recharging point for recharging the riding card or manually recharge the riding card through a mobile phone, the operation is complex, the riding of the user is influenced under the condition that the user forgets to recharge in advance, and the user experience is low.

Disclosure of Invention

The embodiment of the invention provides a riding payment method and device based on credibility, electronic equipment and a storage medium, which can bring riding-before-payment experience to a user and reduce time cost and operation cost required by riding of the user.

The technical scheme of the embodiment of the invention is realized as follows:

The embodiment of the invention provides a riding payment method based on credit, which comprises the following steps:

responding to an opening instruction for the virtual bus card, and presenting a payment authorization key for authorizing a payment mode corresponding to the virtual bus card;

Responding to an authorization instruction triggered based on the payment authorization key, and acquiring the credit of a target user associated with the virtual bus card;

based on the credit degree of the target user, corresponding payment amount is distributed to the virtual bus card;

in response to a first payment order sent over a near field communication connection, deducting an order amount corresponding to the first payment order from the payment amount;

And based on the order amount, sending a second payment order to a payment terminal corresponding to the payment mode, so as to deduct the order amount from the associated payment account of the target user based on the second payment order.

The embodiment of the invention also provides a riding payment device based on the credit, which comprises:

The display module is used for responding to an opening instruction for the virtual bus card and presenting a payment authorization key for authorizing a payment mode corresponding to the virtual bus card;

The acquisition module is used for responding to an authorization instruction triggered based on the payment authorization key and acquiring the credit of the target user associated with the virtual bus card;

the distribution module is used for distributing corresponding payment amount to the virtual bus card based on the credit degree of the target user;

A payment module for deducting an order amount corresponding to a first payment order from the payment amount in response to the first payment order sent through a near field communication connection;

And the sending module is used for sending a second payment order to a payment end corresponding to the payment mode based on the order amount so as to deduct the order amount from the associated payment account of the target user based on the second payment order.

In the above scheme, the device further comprises a correlation module;

the display module is also used for presenting a payment rule corresponding to the payment mode and a determination function item for determining the payment mode;

The association module is used for responding to the operation instruction aiming at the determined functional item triggered according to the payment rule, and associating the virtual bus card with the payment terminal corresponding to the payment mode.

In the above scheme, the acquiring module is further configured to send a credit acquiring request corresponding to the target user;

And receiving a returned credit score for representing the credit degree of the target user.

In the above scheme, the obtaining module is further configured to send, through a sub-application, the credit obtaining request to a parent application running the sub-application.

In the above scheme, the allocation module is further configured to determine a payment amount of the virtual bus card based on a mapping relationship between the credit of the target user, the credit and the payment amount;

and based on the payment amount of the virtual bus card, distributing corresponding payment amount for the virtual bus card.

In the above scheme, the display module is further configured to present, in a view interface, the virtual car card including a car card number, where the car card number is used to identify the virtual car card and indicate that the virtual car card is successfully opened.

In the above scheme, the display module is further configured to present card swiping information and/or payment information corresponding to the virtual bus card through a popup window.

In the above scheme, the acquiring module is further configured to send a card swiping record corresponding to the virtual car card, where the card swiping record includes the amount of the order;

and receiving the returned second payment order generated based on the card swiping record, wherein the payment amount corresponding to the second payment order is the same as the order amount.

In the above scheme, the device further includes:

the recharging module is used for receiving a payment success message corresponding to the second payment order;

and recharging the virtual bus card based on the payment success message, so that the balance of the virtual bus card is the same as the payment amount.

In the above scheme, the payment module is further configured to obtain a balance of the virtual bus card in response to a third payment order sent through a near field communication connection;

and the display module is also used for presenting a prompt message for prompting insufficient balance when the balance is smaller than the order amount of the third payment order.

In the above scheme, the obtaining module is further configured to obtain updated credit of the target user;

the allocation module is further configured to adjust a payment amount allocated to the virtual bus card based on the updated credit of the target user.

In the above scheme, the device further comprises a detection module;

the detection module is used for detecting the near field communication interface to obtain a detection result;

And the display module is also used for presenting a payment authorization key for authorizing the payment mode corresponding to the virtual bus card when the detection result represents that the near field communication interface is detected.

In the above scheme, the device further includes:

the storage module is used for carrying out hash processing on the second payment order to obtain a summary of the second payment order;

Storing a summary of the second payment order to a blockchain network.

The embodiment of the invention also provides electronic equipment, which comprises:

A memory for storing an executable program;

and the processor is used for realizing the riding payment method based on the confidence degree when executing the executable program stored in the memory.

The embodiment of the invention also provides a storage medium which stores an executable program, and when the executable program is executed by a processor, the riding payment method based on the credibility provided by the embodiment of the invention is realized.

The application of the embodiment of the invention has the following beneficial effects:

The corresponding payment amount is distributed for the virtual bus card of the user based on the credit degree of the user, after the user takes bus, the corresponding bus charge is deducted from the distributed payment amount, and then the bus charge is deducted from the payment account of the user, so that the user is subjected to the experience of taking bus first and then paying.

Drawings

Fig. 1A to 1G are interface views of recharging an entity car card through a mobile phone according to the related art;

FIGS. 2A-2H are interface views of related art providing a ride payment through a ride code;

FIG. 3 is a schematic diagram of an alternative architecture of a credit-based ride-through payment system according to an embodiment of the present invention;

fig. 4 is a schematic structural diagram of an electronic device 400 according to an embodiment of the present invention;

FIG. 5A is a schematic diagram of an alternative system architecture of a client running applet, according to an embodiment of the present invention;

FIG. 5B is a schematic diagram of displaying an applet page in a client according to an embodiment of the present invention;

fig. 6 is a schematic flow chart of a ride payment method based on confidence according to an embodiment of the present invention;

FIGS. 7A-7G are interface views of a ride payment based on confidence provided by an embodiment of the present invention;

FIG. 8 is a block chain network application architecture diagram according to an embodiment of the present invention;

FIG. 9 is a block chain architecture diagram of a block chain in a block chain network 80 according to an embodiment of the present invention;

FIG. 10 is a functional architecture diagram of a blockchain network 80 according to an embodiment of the present invention;

FIG. 11 is a flowchart illustrating a method for opening a virtual bus card according to an embodiment of the present invention;

fig. 12A and fig. 12B are schematic flow diagrams of a method for opening a virtual bus card according to an embodiment of the present invention;

Fig. 13A and 13B are schematic flow diagrams of a method for using a virtual bus card according to an embodiment of the present invention;

fig. 14 is a schematic diagram of a composition structure of a riding payment device based on confidence according to an embodiment of the present invention.

Detailed Description

The present invention will be described in further detail with reference to the drawings and examples. It is to be understood that the examples provided herein are for the purpose of illustration only and are not intended to limit the invention. In addition, the embodiments provided below are some of the embodiments for carrying out the present invention, but not all of the embodiments for carrying out the present invention, and the technical solutions described in the embodiments of the present invention may be implemented in any combination without conflict.

It should be noted that, in the embodiments of the present invention, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a method or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such method or apparatus. Without further limitation, an element defined by the phrase "comprising one does not exclude the presence of other related elements in a method or apparatus comprising the element (e.g., a step in a method or an element in an apparatus, e.g., an element may be part of a circuit, part of a processor, part of a program or software, etc.).

For example, the web page processing method provided in the embodiment of the present invention includes a series of steps, but the web page processing method provided in the embodiment of the present invention is not limited to the described steps, and similarly, the web page processing apparatus provided in the embodiment of the present invention includes a series of units, but the apparatus provided in the embodiment of the present invention is not limited to including the explicitly described units, and may include units that are required to be set for acquiring related information or performing processing based on the information.

Before explaining the present invention in further detail, terms and terminology involved in the embodiments of the present invention are explained, and the terms and terminology involved in the embodiments of the present invention are applicable to the following explanation.

1) Parent applications, such as various clients, include applications running in a terminal for providing various services, typically instant messaging clients represented by WeChat.

2) The sub-application program, the program running in the parent application, such as the applet, is based on the program developed in front-end oriented language (e.g. JavaScript) and implementing services in hypertext markup language (HTML, hyper Text Markup Language) pages, which can be immediately interpreted and executed in the client after being downloaded by the client, saving steps installed in the client.

3) Transactions (transactions), which are equivalent to computer terms "transactions," include operations that need to be submitted to a blockchain network for execution, and do not refer solely to transactions in a business context, which embodiments of the present invention follow in view of the terminology "transactions" being colloquially used in blockchain technology.

For example, a deploy (Deploy) transaction is used to install a specified smart contract to a node in the blockchain network and ready to be invoked, a Invoke (Invoke) transaction is used to append records of transactions in the blockchain by invoking the smart contract and to operate on the blockchain's state database, including update operations (including adding, deleting, and modifying key-value pairs in the state database) and query operations (i.e., querying key-value pairs in the state database).

4) A blockchain (Blockchain) is a storage structure of encrypted, chained transactions formed by blocks (blocks).

5) A blockchain network (Blockchain Network) incorporates new blocks into a set of nodes of the blockchain by way of consensus.

6) Ledger (Ledger) is a generic term for blockchains (also known as ledger data) and state databases that are synchronized with the blockchain. The state database records transactions in the blockchain in the form of different types of Key (Key) Value pairs, and is used for supporting quick inquiry of the transactions in the blockchain.

7) A smart contract (Smart Contracts), also referred to as a chain code (Chaincode) or application code, is deployed in a node of the blockchain network, which executes smart contracts invoked in received transactions to update or query key values of the state database.

8) Consensus (Consensus), a process in a blockchain network for agreeing on transactions in blocks among the multiple nodes involved, the agreed blocks will be appended to the tail of the blockchain, and the mechanisms implementing Consensus include Proof of Work (PoW, proof of Work), proof of equity (PoS, proof of status), proof of equity authorization (DPoS, DELEGATED PROOF-of-status), proof of elapsed time (PoET, proof of ELAPSED TIME), and the like.

9) In response to a condition or state representing a dependency of an operation performed, the one or more operations performed may be in real-time or with a set delay when the dependency is satisfied, and without any particular limitation to execution sequencing.

In the related art, a user uses an entity car card to pay car payment in a car trip, so that the user needs to recharge the entity car card in advance in order not to affect normal use, fig. 1A to 1G are interface views of recharging the entity car card through a mobile phone provided in the related art, and a process of recharging the entity car card is described with reference to fig. 1A to 1G.

Firstly, on a view interface (shown in fig. 1A) with a Near Field Communication (NFC) key, a user clicks the NFC key to trigger a mobile phone to jump to a setting interface (shown in fig. 1B) of an NFC function, and clicks a function switch corresponding to the NFC function to trigger the start of the NFC function; the user approaches the physical bus card to the mobile phone, for example, the physical bus card is attached to the back of the mobile phone so as to realize Near Field Communication, the page presented by the mobile phone jumps to a recharging interface (shown in fig. 1C), the user selects a recharging amount, then the page jumps to a payment page, and after the user finishes payment in an associated payment mode, the user writes data into the physical bus card through Near Field Communication so as to finish recharging.

The method for recharging the entity bus card requires manual operation of a user, is complex in flow and long in operation time, influences the bus of the user under the condition that the user forgets to recharge in advance, and is low in user experience.

In the related art, the user can pay by riding through the riding code applet and pay by riding through the riding code, and fig. 2A to 2H are interface views for realizing the payment by riding through the riding code provided in the related art, and a flow for realizing the payment by riding through the riding code will be described with reference to fig. 2A to 2H.

The user opens a client (parent application program), searches for a riding code applet (sub application program) through the searching function of the client, selects the riding code applet from the searched presented applets, presents a view interface (shown in fig. 2B) corresponding to the selected riding code applet, clicks a riding-out button in the view interface to trigger the opening of the riding code, jumps to the opening interface (shown in fig. 2C) of the riding code, clicks the riding-out code to trigger an opening instruction for the riding code, jumps to a payment authorization interface (shown in fig. 2D), opens a password-free payment through the interface, enables riding payment through a charging device with a code scanning function when the user pays based on the riding code, and deducts corresponding riding fees from an associated riding account through the riding fee mode selected by the user in the payment process.

The above-mentioned mode that adopts the sign indicating number of riding to realize riding payment needs to reform transform card swiping equipment (floodgate machine) among the relevant technique, makes it possess and sweeps a yard function, however, need consume a large amount of manpower, material resources to the card swiping equipment reform transform, and the cost is high.

Based on this, the riding payment method, device, electronic equipment, system and storage medium based on the credit degree according to the embodiments of the present invention are provided to at least solve the above-mentioned problems in the related art, and are described below respectively.

Fig. 3 is a schematic diagram of an alternative architecture of a credit-based riding payment system according to an embodiment of the present invention, referring to fig. 3, in order to support an exemplary application, a terminal (including a terminal 400-1 and a terminal 400-2) is connected to a server 200 through a network 300, where the network 300 may be a wide area network or a local area network, or a combination of the two, and a wireless or wired link is used to implement data transmission.

A terminal (such as terminal 400-1) for responding to the opening instruction of the virtual car-taking card triggered by the user and presenting a payment authorization key for authorizing the payment mode of the corresponding virtual car-taking card;

The server 200 is configured to query the database for the trust level of the target user based on the received trust level acquisition request, and return the trust level of the target user to the terminal;

the terminal (such as terminal 400-1) is further configured to receive, through a near field communication connection, a first payment order sent by the card swiping device, and deduct an order amount for the first payment order from a payment amount of the virtual bus card;

The terminal (e.g., terminal 400-1) is further configured to send a second payment order to the payment terminal corresponding to the payment manner based on the order amount, so as to deduct the order amount from the payment account of the associated target user based on the second payment order.

In practical applications, the server 200 may be a single server configured to support various services, or may be configured as a server cluster, and the terminal may be various types of user terminals such as a smart phone, a tablet computer, a notebook computer, etc., or may be a wearable computing device, a Personal Digital Assistant (PDA), a desktop computer, a cellular phone, a media player, a navigation device, a game console, a television, or a combination of any two or more of these data processing devices or other data processing devices.

Next, an electronic device implementing the credit-based ride-through payment method according to an embodiment of the present invention will be described. In some embodiments, the electronic device may be a terminal, and may also be a server. Referring to fig. 4, fig. 4 is a schematic structural diagram of an electronic device 400 according to an embodiment of the present invention, and the electronic device 400 shown in fig. 4 includes a processor 410, a memory 450, a network interface 420, and a user interface 430. The various components in electronic device 400 are coupled together by bus system 440. It is understood that the bus system 440 is used to enable connected communication between these components. The bus system 440 includes a power bus, a control bus, and a status signal bus in addition to the data bus. But for clarity of illustration the various buses are labeled in fig. 4 as bus system 440.

The Processor 410 may be an integrated circuit chip having signal processing capabilities such as a general purpose Processor, such as a microprocessor or any conventional Processor, a digital signal Processor (DSP, digital Signal Processor), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like.

The user interface 430 includes one or more output devices 431, including one or more speakers and/or one or more visual displays, that enable presentation of the media content. The user interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

Memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid state memory, hard drives, optical drives, and the like. Memory 450 optionally includes one or more storage devices physically remote from processor 410.

Memory 450 includes volatile memory or nonvolatile memory, and may also include both volatile and nonvolatile memory. The non-volatile Memory may be a Read Only Memory (ROM) and the volatile Memory may be a random access Memory (RAM, random Access Memory). The memory 450 described in embodiments of the present invention is intended to comprise any suitable type of memory.

In some embodiments, memory 450 is capable of storing data to support various operations, examples of which include programs, modules and data structures, or subsets or supersets thereof, as exemplified below.

An operating system 451 including system programs, e.g., framework layer, core library layer, driver layer, etc., for handling various basic system services and performing hardware-related tasks, for implementing various basic services and handling hardware-based tasks;

a network communication module 452 for accessing other computing devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 including bluetooth, wireless compatibility authentication (WiFi), and universal serial bus (USB, universal Serial Bus), among others;

a presentation module 453 for enabling presentation of information (e.g., a user interface for operating peripheral devices and displaying content and information) via one or more output devices 431 (e.g., a display screen, speakers, etc.) associated with the user interface 430;

An input processing module 454 for detecting one or more user inputs or interactions from one of the one or more input devices 432 and translating the detected inputs or interactions.

In some embodiments, the credit-based riding payment device provided by the embodiments of the present invention may be implemented in software, and fig. 4 shows the credit-based riding payment device 455 stored in the memory 450, which may be software in the form of a program and a plug-in, and includes software modules including a display module 4551, an acquisition module 4552, an allocation module 4553, a payment module 4554, and a transmission module 4555, which are logical, so that any combination or further splitting may be performed according to the implemented functions, and the functions of the respective modules will be described below.

In other embodiments, the credit-based ride-through payment device provided in the embodiments of the present invention may be implemented in hardware, and by way of example, the credit-based ride-through payment device provided in the embodiments of the present invention may be a processor in the form of a hardware decoding processor that is programmed to perform the credit-based ride-through payment method provided in the embodiments of the present invention, for example, the processor in the form of a hardware decoding processor may employ one or more Application specific integrated circuits (ASICs, application SPECIFIC INTEGRATED circuits), DSPs, programmable logic devices (PLDs, programmable Logic Device), complex Programmable logic devices (CPLDs, complex Programmable Logic Device), field-Programmable gate arrays (FPGAs), or other electronic components.

Based on the above description of the credit-based riding payment system and the electronic device according to the embodiments of the present invention, before describing the credit-based riding payment method provided by the embodiments of the present invention, a description is first given of a parent application program and a child application program related to the embodiments of the present invention.

Taking a parent application program as a client and a sub-application program as an applet as an example, fig. 5A is a schematic diagram of an optional system architecture of the running applet of the client provided by the embodiment of the present invention, fig. 5B is a schematic diagram of displaying an applet page in the client provided by the embodiment of the present invention, and in combination with fig. 5A and 5B, when the applet is first run by the client 11 (e.g. the micro-letter client WeChat) provided in the terminal 20, the applet needs to be downloaded, an initialization request is sent to a server of the applet to download the applet, in order to increase the downloading speed, the request can be redirected to the content distribution network 13 (CDN, content Delivery Network), a data packet (Package) of the applet is sent to the client 11 by the content distribution network 13 instead of the server of the applet, so as to realize downloading of the applet, after the applet is initialized, the applet is sent to the applet by an interpreter, the applet is updated by the page, and the applet is displayed by the JSON, and the data is further rendered by the applet to the client 12.

Based on the above description of the parent application and the child application, a riding payment method based on confidence provided by the embodiment of the invention is described next. Fig. 6 is a flow chart of a credit-based ride-through payment method according to an embodiment of the present invention, and fig. 7A to 7G are interface views of a credit-based ride-through payment according to an embodiment of the present invention, and in some embodiments, the credit-based ride-through payment method according to an embodiment of the present invention may be implemented by a terminal, or implemented by a server and a terminal in cooperation, and in a terminal embodiment, for example, implemented by a terminal 400-1 in fig. 3, and will be described with reference to fig. 3, 6, and 7A to 7G.

In step 601, the terminal responds to an opening instruction for the virtual bus card, and presents a payment authorization key for authorizing a payment mode of the corresponding virtual bus card.

Here, in actual implementation, since the terminal is required to have the NFC function for carrying out the riding payment based on the virtual riding card, the NFC function of the terminal needs to be detected before the virtual riding card is opened to determine whether the terminal has the NFC function, specifically, the terminal detects the near field communication interface to obtain a detection result, and when the detection result characterizes that the near field communication interface is detected, the terminal is considered to have the NFC function, and further, when an opening instruction for the virtual riding card is received, a payment authorization key for authorizing a payment mode of the corresponding virtual riding card can be presented.

In some embodiments, a virtual car card client is provided on the terminal, the terminal presents an opening interface including one or more virtual car cards by running the virtual car card client, the user selects a virtual car card to be opened, a click operation on the selected virtual car card triggers an opening instruction on the virtual car card, and a payment authorization key for authorizing a payment mode of the corresponding virtual car card is presented on a payment authorization interface.

Here, the virtual car card is to realize the simulation of the physical car card on the terminal with the NFC function, and realize the function of the built-in car card of the mobile phone.

In other embodiments, a parent application program, such as an instant messaging client, is provided on the terminal, a applet searching function provided by the parent application program is used to search for a "riding card" applet, a search result interface (shown in fig. 7A) corresponding to the search for the "riding card" applet is presented, a user clicks the "riding card" applet on the search result interface to implement page skip to applet page (shown in fig. 7B), the user selects a virtual riding card desired to be opened, an opening instruction for the virtual riding card is triggered by clicking operation (such as clicking an "instant opening" button in the view interface shown in fig. 7B to trigger an opening instruction for the virtual riding card), the applet implements page skip to payment authorization interface (shown in fig. 7C), and a payment authorization button for authorizing a payment mode corresponding to the virtual riding card is presented on the payment authorization interface.

In some embodiments, the terminal also presents a payment rule corresponding to the payment mode and a determination function item for determining the payment mode on a payment authorization interface, and associates the virtual bus card with a payment terminal corresponding to the payment mode in response to an operation instruction for the determination function item triggered according to the payment rule.

Taking an execution main body as an applet as an example, referring to fig. 7C, the applet displays a payment mode of "change" on a payment authorization interface, and the change payment is used for recharging when the balance in the card is insufficient after taking a bus according to a payment rule of "change", where the payment rule of the corresponding payment mode is used for explaining the payment mode, and when a user triggers an operation instruction for determining a function item according to the payment rule, the applet realizes the virtual bus card and a payment end corresponding to the payment mode, namely a client for running the applet.

Step 602, responding to an authorization instruction triggered by a payment authorization key, and acquiring the credit of a target user associated with the virtual bus card.

In some embodiments, when the virtual car-taking card client is provided on the terminal, the virtual car-taking card client sends a credit acquisition request of a target user associated with the virtual car-taking card to the background server in response to an authorization instruction triggered based on the payment authorization key so as to acquire the credit of the target user returned by the background server. In practical implementation, the background server may store the credits of multiple users, and query corresponding credits according to the target user identifier carried in the credit acquisition request, or forward the credit acquisition request to the server storing the user credits information based on the target user identifier of the target user, so as to acquire the credits of the target user, and return the credits to the virtual car-taking client.

The confidence level refers to the user's confidence level reflected in social reputation, economic status, commodity trade performance, etc., and in practical application, the user's confidence level can be represented by credit score, and the credit score corresponds to the confidence level.

In other embodiments, when the execution subject is an applet, the applet transmits a credit acquisition request corresponding to the target user to the client running the applet in response to an authorization instruction triggered based on the payment authorization key, so that the client running the applet acquires the credit of the target user from the background server and returns the credit to the applet.

Step 603, distributing corresponding payment amount for the virtual bus card based on the credit degree of the target user.

In some embodiments, a mapping relationship between credit and payment amount is set, the terminal determines the payment amount of the virtual bus card based on the mapping relationship between the credit and payment amount of the target user, and can allocate a corresponding payment amount to the virtual bus card based on the payment amount of the virtual bus card.

In some embodiments, the credit is characterized by a credit score, and the terminal may assign a corresponding payment amount to the virtual bus card by determining a score range in which the credit score of the target user is located, determining a payment amount of the virtual bus card corresponding to the target user according to the determined score range, and assigning the corresponding payment amount to the virtual bus card based on the determined payment amount.

For example, assuming that the credit score is a percentile, setting a score range of the credit score to include [0,60], [60,80], [80,100], wherein a payment amount corresponding to the score range [0,60] is 5 yuan, a payment amount corresponding to the score range [60,80] is 10 yuan, a payment amount corresponding to the score range [80,100] is 15 yuan, the obtained credit score of the target user is 75, the score range in which the credit score is located is determined to be [60,80], and accordingly, the payment amount of the virtual car card corresponding to the target user can be determined to be 10 yuan, and the corresponding payment amount is allocated to the virtual car card to be 10 yuan.

In other embodiments, the credit score is used to characterize the credit, and the terminal may allocate a corresponding payment amount to the virtual bus card by determining a credit level corresponding to the credit score of the target user, determining the payment amount of the virtual bus card based on the determined credit level, the mapping relationship between the credit level and the payment amount, and allocating a corresponding payment amount to the virtual bus card based on the payment amount of the virtual bus card.

In some embodiments, after the terminal allocates the corresponding payment amount to the virtual car taking card, the terminal presents corresponding prompt information, the prompt information is used for prompting the user to take the car without recharging the virtual car taking card as shown in fig. 7D, prompt information of 'successful credit giving, no recharging, and paying the car fee through the payment card after taking the car' is presented on a view interface, wherein the credit giving is that a certain amount is granted to the virtual car taking card of the user in advance according to the credit condition of the user, the user does not need to recharge in advance when using the virtual car taking card, the virtual car taking card can be directly brushed to pay the car fee when the car taking fee is lower than the credit giving amount, the payment card is signed with the user by the payment card in advance, and the payment card is deducted by using a contract account.

In some embodiments, after the terminal allocates a corresponding payment amount for the virtual ride card, the terminal presents the virtual ride card containing a ride card number in the view interface, the ride card number being used to identify the virtual ride card, indicating that the virtual ride card was successfully opened. Referring to fig. 7E, the terminal presents a virtual car card (i.e. a cloud traffic card) with successful opening in the view interface, where the virtual car card includes a corresponding card number to uniquely identify the virtual car card and indicate that the virtual car card is successfully opened.

Step 604, in response to the first payment order sent over the near field communication connection, deducting an order amount corresponding to the first payment order from the payment amount.

In practical application, after the virtual car taking card is successfully opened, the user can take the car by swiping the card based on the virtual car taking card, specifically, the user holds the terminal close to the card-swiping device, so that NFC communication connection is established between the terminal and the card-swiping device, the card-swiping device sends a first payment order to the terminal through near field communication connection, and the terminal deducts the order amount corresponding to the first payment order from the payment amount corresponding to the virtual car taking card.

In some embodiments, after deducting the order amount corresponding to the first payment order from the payment amount, the terminal presents card swiping information and/or payment information corresponding to the virtual bus card through a popup window, wherein the card swiping information indicates that the card swiping is successful or failed, and the payment information indicates the order amount corresponding to the first payment order deducted by the card swiping. Referring to fig. 7F, after the terminal swipes the card successfully and deducts the order amount corresponding to the first payment order from the payment amount, the information of the successful swipe card and the trusted payment of 5 elements is presented through the popup window.

Step 605, based on the order amount, sending a second payment order to the payment terminal corresponding to the payment mode, so as to deduct the order amount from the payment account of the associated target user based on the second payment order.

In practical implementation, before the terminal sends the second payment order to the payment end corresponding to the payment mode, the terminal needs to acquire the second payment order, and in some embodiments, the terminal may acquire the second payment order by sending a card swiping record of the corresponding virtual bus card containing the amount of the order, and receiving a returned second payment order generated based on the card swiping record, where the payment amount corresponding to the second payment order is the same as the amount of the order.

The virtual ride card client sends a corresponding virtual ride card swipe record containing the amount of the order to the background server, and receives a second payment order generated based on the swipe record returned by the background server.

Illustratively, the applet sends a swipe record of the corresponding virtual ride card containing the amount of the order to a backend server of the applet, and receives a second payment order generated based on the swipe record returned by the backend server of the applet.

In some embodiments, when the execution subject is an applet, the applet sends a second payment order to the payment end corresponding to the payment method based on the amount of the order, that is, sends the second payment order to the client running the applet, so that the client deducts the amount of the order from the payment account of the associated target user based on the second payment order.

Correspondingly, after deducting the order amount from the payment account of the associated target user, the terminal presents corresponding deduction success prompt information, and referring to fig. 7G, presents deduction success prompt information with deduction amount of 5 yuan on the WeChat payment result interface.

In some embodiments, after the terminal sends the second payment order to the riding payment terminal corresponding to the payment mode, the terminal receives a payment success message corresponding to the payment order, and based on the payment success message, the virtual riding card is recharged, so that the balance of the virtual riding card is the same as the payment amount. That is, after each time the user takes a car, the corresponding car fee is deducted from the payment amount allocated to the virtual car taking card of the user based on the credit of the user, and then the car fee is deducted from the associated payment account, when the fee deduction is successful, the virtual car card of the user is automatically recharged, so that the balance of the virtual car card is the same as the originally allocated payment amount, the user can take the car smoothly every time, the user does not need to recharge the virtual car taking card, and the travel of the user is greatly facilitated.

In practical application, after a user takes a bus, the situation that deduction in a payment account of the related user fails, so that a terminal cannot recharge a virtual bus card of the user and the balance is insufficient exists, in the case, when the user uses the virtual bus card to swipe the card for taking the bus, the terminal receives a third payment order sent by the card swiping device through near field communication connection, obtains the balance of the virtual bus card, and when the balance is determined to be smaller than the order amount of the third payment order, presents a prompting message prompting the insufficient balance, so that the user manually completes fee deduction when riding the bus last time, and automatic recharging of the virtual bus card by the terminal is realized.

In practical application, the credit of the user is changed due to the increase of the consumption of the user, the change of the performance condition and the like, and at the moment, the terminal correspondingly adjusts the payment amount allocated to the virtual car taking card based on the changed credit of the user, specifically, the terminal acquires the updated credit of the target user and adjusts the payment amount allocated to the virtual car taking card based on the updated credit of the target user.

By applying the embodiment of the invention, the corresponding payment amount is distributed for the virtual bus card of the user based on the credit of the user, after the user takes bus, the corresponding bus charge is firstly deducted from the distributed payment amount, and then the bus charge is deducted from the payment account of the user, so that the user is subjected to experience of taking bus before paying, and meanwhile, the user does not need to recharge the virtual bus card, so that the time cost and the labor cost required by taking bus of the user are greatly reduced, and the bus experience of the user is improved.

In some embodiments, after the terminal obtains the second payment order, the terminal may further store the second payment order in the blockchain network in combination with blockchain technology, specifically, the terminal hashes the second payment order to obtain a digest of the second payment order, and stores the digest of the second payment order in the blockchain network, so that the payment terminal verifies the authenticity of the second payment order received from the terminal after obtaining the second payment order from the blockchain network, which will be described in detail below.

The payment terminal firstly checks the authenticity of the received second payment order after receiving the second payment order sent by the terminal and before deducting the amount of the order from the payment account of the associated target user, so as to execute the deduction operation from the payment account after the verification is passed, specifically, the payment terminal generates the transaction for obtaining the second payment order, sends the generated transaction to the node of the blockchain network, so that the node returns the abstract of the second payment order to the payment terminal after the transaction is consensus, the payment terminal carries out hash processing on the second payment order received from the terminal, and matches the hash result with the abstract of the second payment order obtained from the blockchain network, and when the matching is successful, the verification is determined to be passed.

The blockchain network in the embodiments of the present invention is described next. Fig. 8 is a schematic diagram of an application architecture of a blockchain network according to an embodiment of the present invention, including a service entity 50, an authentication center 70, and a blockchain network 80 (illustrated by an example as a consensus node 81-1 to a consensus node 81-3), which are described below.

The type of blockchain network 80 is flexible and diverse, and may be any of public, private, or federated chains, for example. Taking public chains as an example, any electronic equipment of a service body, such as a user terminal and a server, can access the blockchain network 80 without authorization, taking alliance chains as an example, electronic equipment (such as a terminal/server) under the jurisdiction of the service body after the service body obtains authorization can access the blockchain network 80, and at the moment, the electronic equipment becomes a client node in the blockchain network 80.

In some embodiments, the client node may be implemented by default or selectively (e.g., depending on the specific business needs of the business entity) as a watcher of the blockchain network 80 only, i.e., to provide functionality to support the business entity to initiate transactions (e.g., for storing data in the uplink or querying data on the link), for the function of the consensus node 81 of the blockchain network 80 (e.g., consensus node 81-1), such as ordering, consensus services, ledger functions, etc. Thus, the data and service processing logic of the service body can be migrated to the blockchain network 80 to the greatest extent, and the credibility and traceability of the data and service processing process are realized through the blockchain network 80.

The consensus nodes in the blockchain network 80 receive transactions submitted from client nodes (e.g., client nodes 51 affiliated with the business entity 50) of different business entities (e.g., business entity 50), execute the transactions to find and return summaries of the second payment orders, and various intermediate or final results of executing the transactions may be returned to the client nodes of the business entity for display.

For example, client node 51 may subscribe to events of interest in blockchain network 80, such as transactions occurring in a particular organization/channel in blockchain network 80, with corresponding transaction notifications pushed to client node 51 by consensus node 81, triggering corresponding business logic in client node 51.

An exemplary application of the blockchain is illustrated with the business entity accessing the blockchain network to effect the retrieval of the second payment order summary.

Referring to fig. 8, a service entity 50 is a payment service platform, registers from an authentication center 70 to obtain a digital certificate, where the digital certificate includes a public key of the service entity, and a digital signature signed by the authentication center 70 with respect to the public key and identity information of the service entity, is used to be attached to a transaction together with the digital signature of the service entity with respect to the transaction, and is sent to a blockchain network, so that the blockchain network can take the digital certificate and signature from the transaction, verify the reliability of the message (i.e. whether it has not been tampered) and the identity information of the service entity sending the message, and the blockchain network can verify according to the identity, for example, whether it has authority to initiate the transaction. Clients operated by electronic devices (e.g., terminals or servers) under the control of the service agents may request access to the blockchain network 80 as client nodes.

The client node 51 of the service entity 50 is configured to, when receiving the second payment order sent by the terminal, generate a transaction for obtaining a second payment order digest stored in the blockchain, specify in the transaction a smart contract that needs to be invoked to implement the obtaining operation of the second payment order digest, and parameters that are transferred to the smart contract, the transaction further carries a digital certificate of the client 51, a signed digital signature (e.g., obtained by encrypting the digest of the transaction using a private key in the digital certificate of the client 51), and broadcast the transaction to the consensus node in the blockchain network 80.

When the consensus node in the blockchain network 80 receives a transaction, the digital certificate and the digital signature carried by the transaction are verified, after the verification is successful, whether the transaction main body 50 has transaction permission is confirmed according to the identity of the transaction main body 50 carried in the transaction, and any one verification judgment of the digital signature and the permission verification can cause the transaction to fail. After verification is successful, the node's own digital signature (e.g., encrypted with the private key of node 81-1) is signed and broadcast in blockchain network 80.

After receiving a successful transaction, the consensus node in the blockchain network 80 fills the transaction into a new block and broadcasts it. When the new block is broadcast by the consensus node in the blockchain network 80, a consensus process is performed on the new block, if the consensus is successful, the new block is added to the tail part of the blockchain stored by the new block, and the state database is updated according to the transaction result, so as to execute the transaction in the new block, namely, for the submitted transaction for acquiring the second payment order abstract, the key value pair corresponding to the second payment order abstract is queried from the state database, and the transaction result is returned.

As an example of a blockchain, referring to fig. 9, fig. 9 is a schematic diagram of a blockchain structure in a blockchain network 80 according to an embodiment of the present invention, where a header of each block may include hash values of all transactions in the block, and also include hash values of all transactions in a previous block, and a record of a newly generated transaction is filled into the block and after passing through a node in the blockchain network, is appended to a tail of the blockchain to form a chain growth, and a chain structure based on the hash values between the blocks ensures tamper resistance and forgery resistance of transactions in the block.

An exemplary functional architecture of the blockchain network provided by the embodiment of the present invention is described below, referring to fig. 10, fig. 10 is a schematic diagram of the functional architecture of the blockchain network 80 provided by the embodiment of the present invention, including an application layer 1, a consensus layer 2, a network layer 3, a data layer 4, and a resource layer 5, which are described below.

The resource layer 5 encapsulates computing, storage and communication resources that implement the various nodes 81 in the blockchain network 80.

Data layer 4 encapsulates various data structures that implement the ledger, including blockchains implemented with files in the file system, a state database of key values, and presence certificates (e.g., hash trees of transactions in the blocks).

The network layer 3 encapsulates the functions of Point-to-Point (P2P) network protocols, data propagation mechanisms and data verification mechanisms, access authentication mechanisms and service body identity management.

Wherein the P2P network protocol implements communication between nodes 81 in the blockchain network 80, a data propagation mechanism ensures propagation of transactions in the blockchain network 80, a data verification mechanism is used to implement reliability of data transmission between nodes 81 based on cryptography methods (e.g., digital certificates, digital signatures, public/private key pairs), an access authentication mechanism is used to authenticate identities of service principals joining the blockchain network 80 according to actual service scenarios and to give the service principals authority to access the blockchain network 80 when authentication passes, and a service principal identity management is used to store identities of service principals allowed to access the blockchain network 80, and authorities (e.g., types of transactions that can be initiated).

Consensus layer 2 encapsulates the functionality of the mechanism by which node 81 in blockchain network 80 agrees on blocks (i.e., consensus mechanism), transaction management, and ledger management. The consensus mechanism comprises consensus algorithms such as POS, POW and DPOS, and the like, and supports the pluggable of the consensus algorithms.

The transaction management is used for verifying the digital signature carried in the transaction received by the node 81, verifying the identity information of the service entity, judging and confirming whether the service entity has authority to conduct the transaction according to the identity information (reading related information from the service entity identity management), and for the service entity which obtains the authorization of accessing the blockchain network 80, all the service entity has the digital certificate issued by the authentication center, and the service entity signs the submitted transaction by utilizing the private key in the own digital certificate so as to declare the legal identity of the service entity.

Ledger management is used to maintain blockchains and state databases. And executing the transaction in the block with the consensus, updating the key value pairs in the state database when the transaction comprises an updating operation, querying the key value pairs in the state database when the transaction comprises a querying operation and returning a query result to the client node of the business entity. The query operation of multiple dimensions of the state database is supported, wherein the query operation comprises the steps of querying a block according to a block serial number (such as a hash value of a transaction), querying the block according to the hash value of the block, querying the block according to the transaction serial number, querying the transaction according to the transaction serial number, querying account number data of a service body according to an account number (serial number) of the service body, and querying a blockchain in a channel according to a channel name.

The application layer 1 encapsulates various services that can be implemented by the blockchain network, including tracing, certification and verification of transactions, etc.

And then, taking the operation of the riding card applet in the instant messaging client to realize the opening and use of the riding card as an example, and continuing to explain the riding payment method based on the confidence degree provided by the embodiment of the invention. Fig. 8 is a flowchart of a method for opening a virtual bus card according to an embodiment of the present invention, referring to fig. 11, where the method for opening a virtual bus card according to an embodiment of the present invention includes:

step 701, the instant communication client runs the riding card applet.

In practical implementation, the terminal has NFC function, and is provided with an instant messaging client (e.g., a micro-messaging client), and the riding card applet is searched for by the applet searching function provided by the instant messaging client, and the riding card applet can be operated after the source code is downloaded.

Step 702, the ride card applet presents a payment authorization key for authorizing a payment method for a corresponding virtual ride card in response to an activation instruction for the virtual ride card.

In practical application, one or more virtual bus cards are presented on an applet page, namely an opening interface of the virtual bus card for a user to select, the user selects the virtual bus card which wants to be opened, an opening instruction for the virtual bus card is triggered by clicking the displayed virtual bus card, the bus card applet responds to the opening instruction triggered by the user, a payment authorization interface is presented, and a payment authorization key for authorizing a payment mode of the corresponding virtual bus card is presented on the payment authorization interface.

In actual implementation, the riding card applet also presents a determining function item for determining a payment mode on the payment authorization interface so as to associate the virtual riding card with the instant messaging client based on the determining function item.

Step 703, the riding card applet responds to the authorization instruction triggered by the payment authorization key to send the credit acquisition request of the target user to the instant messaging client.

Step 704, the instant messaging client returns the credit score of the target user to the riding card applet.

Step 705, the ride card applet determines the payment amount of the virtual ride card based on the credit score of the target user.

In actual implementation, the credit score is used to characterize the credit score, and the ride card applet can determine the payment amount of the virtual ride card by:

The riding card applet determines the scoring range of the credit score of the target user, and determines the payment amount of the virtual riding card corresponding to the target user according to the determined scoring range.

Step 706, the card applet allocates a corresponding payment amount to the virtual card based on the determined payment amount.

Step 707, the riding card applet receives the first payment order through the near field communication connection with the card swiping device, and deducts the order amount corresponding to the first payment order from the payment amount.

Step 708, the car card applet presents card swiping information and/or payment information corresponding to the virtual car card through the popup window.

Here, the card swiping information is used for indicating success or failure of card swiping, and the payment information is used for indicating the order amount of the corresponding first payment order deducted by the card swiping.

Step 709, the riding card applet generates and sends a second payment order to the instant messaging client based on the order amount of the first payment order.

Here, the payment amount corresponding to the second payment order is the same as the order amount.

The instant messaging client deducts the order amount from the associated target user's payment account 710.

And 711, the instant communication client sends a message of successful payment of the second payment order to the riding card applet.

Step 712, the ride card applet charges the virtual ride card.

When the method is actually implemented, after receiving the message that the second payment order is successfully paid, the riding card applet automatically charges the virtual riding card, so that the balance of the virtual riding card is the same as the determined payment amount.

The method for paying the bus based on the credit degree provided by the embodiment of the invention is continuously described by taking the example of running the small program of the bus card in the instant messaging client to realize the opening and the use of the bus card.

Fig. 12A and fig. 12B are schematic diagrams illustrating a process of opening a virtual bus card according to an embodiment of the present invention, and the process of opening a virtual bus card according to an embodiment of the present invention is described with reference to fig. 12A and fig. 12B.

Step 801, the instant messaging client runs a ride card applet.

In practical implementation, when the instant messaging client (e.g., the WeChat client) runs the riding card applet for the first time, the applet needs to be downloaded, namely, the source code of the riding card applet is acquired, then the instant messaging client loads the riding card applet page by interpreting the code of the riding card applet, and the instant messaging client can directly run without repeated downloading in the using process of the riding card applet.

Step 802, the riding card applet detection terminal has an NFC function.

Here, in actual implementation, the riding card applet may implement detection of the NFC function of the terminal by detecting the NFC function interface.

Step 803, the user applies to open the one-card.

The one-card is a virtual riding card, a plurality of available one-cards can be presented on a riding card applet page, and a user triggers an opening instruction for one card through clicking operation for the selected one card.

Step 804, the riding card applet sends a signed-up password-free payment request to the instant messaging client.

In practical implementation, after the user triggers the opening instruction for a card, the applet realizes that the page jumps to the "open secret payment-free" interface (i.e. the payment authorization interface in the foregoing embodiment), and when the user clicks the "open secret payment-free" button presented in the interface, the riding card applet is triggered to send a signed secret payment-free request to the instant messaging client.

Step 805, the instant messaging client returns a sign-up success message to the ride card applet.

Here, after receiving the signing password-free payment request sent by the riding card applet, the instant communication client associates the corresponding one-card with the selected fee deduction mode to deduct the fee after riding the vehicle by the user.

Step 806, the ride card applet presents a successful sign-up message.

And after the riding card applet receives the signing success message returned by the instant communication client, correspondingly, the signing success message is presented to the user.

Step 807, the riding card applet queries the user information and performs trust.

Specifically, the riding card applet acquires user information, such as a credit score of a user, from the instant messaging client, and then allocates a corresponding payment amount to the one-card of the user based on the credit score of the user.

Step 808, the card riding applet successfully receives the credit card information and presents the card opening success information.

In actual implementation, after the car riding card applet distributes corresponding payment amount for the one-card of the user, information of success of credit giving and success of card opening is respectively displayed to the user.

Fig. 13A and 13B are schematic diagrams of a flow of using a virtual car card according to an embodiment of the present invention, and the flow of using a virtual car card according to an embodiment of the present invention is described with reference to fig. 13A and 13B.

And step 901, the one-card cloud server charges the one-card in advance.

Here, after the one-card communication of the user is successful, the one-card of the user is automatically recharged based on the credit degree (such as credit score) of the user, that is, the one-card of the user is allocated with the corresponding payment amount.

Step 902, entering a one-card applet.

In practical application, when a user needs to pay by bus with the successfully opened one-card, the user triggers the instant communication client to run the one-card applet.

Step 903, the one-card applet detecting terminal has an NFC function.

Step 904, the user triggers to request the one-card data.

Here, in actual implementation, the user triggers the request for the one-card data by a click operation for the presented one-card.

Step 905, the one-card applet requests one-card data from the one-card cloud server.

And 906, the one-card cloud server transmits one-card data to the one-card applet.

Step 907, the one-card applet presents the one-card data to the user.

Step 908, the gate sends a deduction success message to a cartoon applet.

When the user mobile phone is close to the gate card swiping sensing position, the gate deducts the bus charge in one card through NFC connection with the one-card applet.

Step 909, the one-card applet displays the "card swipe successful" popup.

When the method is actually implemented, after the one-card deduction is successful, the balance of the corresponding one-card is deducted.

Step 910, the one-card applet generates a top-up order.

In actual implementation, the one-card applet generates a corresponding recharge order based on the deduction success message transmitted by the gate topology.

Step 911, the one-card applet sends the recharge order to the instant messaging client.

Step 912, the instant messaging client initiates a substitute button.

In actual implementation, after receiving the recharge order sent by the one-card applet, the instant messaging client deducts the corresponding riding fee from the account of the associated user.

And 913, the instant messaging client sends a payment success message to the one-card applet.

Step 914, the one-card applet presents a payment success message to the user.

Step 915, the one-card applet sends the order for successful recharging to the one-card cloud server.

And step 916, recharging the one-card by the one-card cloud server.

The riding payment device based on the confidence level provided by the embodiment of the invention is continuously described. Fig. 14 is a schematic diagram of a composition structure of a credit-based riding payment device according to an embodiment of the present invention, referring to fig. 14, a credit-based riding payment device 455 according to an embodiment of the present invention includes:

A display module 4551 configured to respond to an activation instruction for a virtual car card, and present a payment authorization key for authorizing a payment mode corresponding to the virtual car card;

An obtaining module 4552, configured to obtain a credit of the target user associated with the virtual car card in response to an authorization instruction triggered based on the payment authorization key;

An allocation module 4553, configured to allocate a corresponding payment amount to the virtual bus card based on the credit of the target user;

A payment module 4554 for deducting an order amount corresponding to a first payment order from the payment amount in response to the first payment order sent over a near field communication connection;

and the sending module 4555 is configured to send a second payment order to a payment end corresponding to the payment manner based on the order amount, so as to deduct the order amount from the associated payment account of the target user based on the second payment order.

In some embodiments, the apparatus further comprises an association module;

In some embodiments, the obtaining module is further configured to send a credit obtaining request corresponding to the target user;

In some embodiments, the obtaining module is further configured to send, by a sub-application, the credit obtaining request to a parent application running the sub-application.

In some embodiments, the allocation module is further configured to determine a payment amount of the virtual bus card based on a mapping relationship between the credit of the target user, the credit and the payment amount;

In some embodiments, the display module is further configured to present the virtual ride card including a ride card number in a view interface, where the ride card number is used to identify the virtual ride card, indicating that the virtual ride card was successfully opened.

In some embodiments, the display module is further configured to present card swiping information and/or payment information corresponding to the virtual bus card through a popup window.

In some embodiments, the obtaining module is further configured to send a card swipe record corresponding to the virtual ride card that includes the order amount;

In some embodiments, the apparatus further comprises:

In some embodiments, the payment module is further configured to obtain a balance of the virtual ride card in response to a third payment order sent over a near field communication connection;

In some embodiments, the obtaining module is further configured to obtain updated credit of the target user;

In some embodiments, the apparatus further comprises a detection module;

It should be noted that the description of the apparatus is similar to the description of the method, and the description of the beneficial effects of the method is not repeated, and for the technical details not disclosed in the apparatus according to the embodiment of the present invention, please refer to the description of the embodiment of the method of the present invention.

A memory for storing an executable program;

And the processor is used for realizing the bus taking payment method based on the confidence degree provided by the embodiment of the invention when executing the executable program stored in the memory.

The embodiment of the invention also provides a storage medium storing executable instructions, wherein the executable instructions are stored, and when the executable instructions are executed by a processor, the processor is caused to execute the bus riding payment method based on the credibility provided by the embodiment of the invention.

All or part of the steps of the embodiments may be performed by hardware associated with program instructions, and the foregoing program may be stored in a computer readable storage medium, which when executed, performs the steps including the method embodiments described above, where the foregoing storage medium includes various media capable of storing program code, such as a mobile storage device, a random access Memory (RAM, random Access Memory), a Read-Only Memory (ROM), a magnetic disk, or an optical disk.

Or the above-described integrated units of the invention may be stored in a computer-readable storage medium if implemented in the form of software functional modules and sold or used as separate products. Based on such understanding, the technical solution of the embodiments of the present invention may be embodied essentially or in a part contributing to the related art in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the methods described in the embodiments of the present invention. The storage medium includes various media capable of storing program codes such as a removable storage device, a RAM, a ROM, a magnetic disk or an optical disk.

The foregoing is merely illustrative of the present invention, and the present invention is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A ride-through payment method based on confidence, characterized in that it is applied to a mobile terminal, the method comprising:

The method comprises the steps of receiving a returned payment order generated based on a card record and corresponding to the card record, obtaining a digest of the second payment order by hashing the second payment order, storing the digest of the second payment order to a blockchain network, generating a transaction for storing the second payment order, sending the generated transaction to a node of the blockchain network, so that the node stores the second payment order to the blockchain network after consensus of the transaction, sending the second payment order to a payment terminal corresponding to a payment mode, generating a transaction for obtaining the second payment order by the payment terminal after receiving the second payment order sent by a terminal, designating an intelligent contract required to be invoked by an obtaining operation for realizing the digest of the second payment order in the transaction, carrying a digital certificate and a digital signature of a client to the node of the blockchain network, sending the generated transaction to the node to the second payment order to the node, and then sending the second payment order to the payment terminal corresponding to the payment mode, and subtracting the payment terminal from the payment terminal corresponding to the payment mode, and successfully obtaining the payment order from the payment network, and determining a successful payment account, and a payment account is obtained by matching the payment terminal to the payment terminal, so that the balance of the virtual ride card is the same as the payment amount.

2. The method according to claim 1, wherein the method further comprises:

presenting a payment rule corresponding to the payment means and a determination function item for determining the payment means;

And responding to an operation instruction aiming at the determined functional item triggered according to the payment rule, and associating the virtual bus card with a payment terminal corresponding to the payment mode.

3. The method of claim 1, wherein the obtaining the credit of the target user associated with the virtual ride card comprises:

sending a credit acquisition request corresponding to the target user;

4. A method according to claim 3, wherein said sending a credit acquisition request for said target user comprises:

And sending the credit acquisition request to a parent application program running the child application program through the child application program.

5. The method of claim 1, wherein the assigning the virtual ride card a respective payment amount based on the credit of the target user comprises:

Determining the payment amount of the virtual bus card based on the mapping relation of the credit, the credit and the payment amount of the target user;

6. The method of claim 1, wherein after the assigning the respective payment amount to the virtual ride card, the method further comprises:

And presenting the virtual car card containing a car card number in a view interface, wherein the car card number is used for identifying the virtual car card and indicating that the virtual car card is successfully opened.

7. The method of claim 1, wherein after deducting an order amount corresponding to the first payment order from the payment amount, the method further comprises:

and presenting card swiping information and/or payment information corresponding to the virtual bus card through a popup window.

8. The method of claim 1, wherein the sending a swipe record corresponding to the virtual ride card containing the order amount, receiving the returned second payment order generated based on the swipe record comprises:

the applet transmits the card swiping record containing the corresponding virtual bus card of the order amount to a background server of the applet, and receives a second payment order generated based on the card swiping record returned by the background server of the applet.

9. The method according to claim 1, wherein the method further comprises:

When a consensus node in the blockchain network receives a transaction, verifying a digital certificate and a digital signature carried by the transaction, after the verification is successful, according to the identity of a business body carried in the transaction, determining whether the business body has transaction authority, wherein any verification judgment failure in the digital signature and the authority verification can cause the transaction failure, signing the digital signature of the node after the verification is successful, and continuing broadcasting in the blockchain network.

10. The method according to claim 1, wherein the method further comprises:

Obtaining a balance of the virtual ride card in response to a third payment order sent over a near field communication connection;

and when the balance is smaller than the order amount of the third payment order, presenting a prompting message for prompting insufficient balance.

11. The method according to claim 1, wherein the method further comprises:

Acquiring updated credit of the target user;

And adjusting the payment amount distributed to the virtual bus card based on the updated credit degree of the target user.

12. A ride-on payment device based on confidence, characterized in that it is applied to a mobile terminal, said device comprising:

The sending module is used for sending the card swiping record of the corresponding virtual bus card containing the order amount based on the order amount; the method comprises the steps of receiving a returned second payment order generated based on a card swiping record, wherein the payment amount corresponding to the second payment order is the same as the order amount, carrying out hash processing on the second payment order to obtain a digest of the second payment order, storing the digest of the second payment order to a blockchain network, generating a transaction for storing the second payment order, sending the generated transaction to a node of the blockchain network, enabling the node to store the second payment order to the blockchain network after consensus of the transaction, sending the second payment order to a payment terminal corresponding to the payment mode, after receiving the second payment order sent by a terminal, the payment terminal generates a transaction for obtaining the second payment order, specifies a smart contract required to be invoked by an obtaining operation of the digest of the second payment order in the transaction, and a parameter transferred to the smart contract, further carries a digital certificate and a signed digital signature of a client, sending the generated transaction to the node of the blockchain network, enabling the node to return the digest of the second payment order to a payment terminal after consensus of the transaction, carrying out hash processing on the second payment order received by the node to a terminal, carrying out successful payment order obtaining and a payment card corresponding to the second payment order, and carrying out successful payment account matching on the payment card, and a payment account is determined to be successful by a payment card, when the payment card is successfully obtained by a user, and a payment card is matched with the payment account, a payment card is obtained based on the payment card, and a payment card is successfully obtained, and a payment card is obtained based on the payment card, so that the balance of the virtual ride card is the same as the payment amount.

13. An electronic device, the electronic device comprising:

A memory for storing an executable program;

A processor for implementing the credit-based ride-on payment method according to any one of claims 1 to 11 when executing the executable program stored in the memory.

14. A storage medium storing an executable program which, when executed by a processor, implements the credit-based ride-on payment method according to any one of claims 1 to 11.