CN113807840A

CN113807840A - Method, server and system for supporting local payment by multiple payment terminals of same user

Info

Publication number: CN113807840A
Application number: CN202111025787.3A
Authority: CN
Inventors: 刘高峰
Original assignee: Individual
Current assignee: Individual
Priority date: 2021-09-03
Filing date: 2021-09-03
Publication date: 2021-12-17

Abstract

The invention discloses a method, a server and a system for supporting local payment by a plurality of payment terminals of the same user. The method comprises the following steps: setting a plurality of unique identification information under a user account, wherein each unique identification information respectively establishes a corresponding local payment asset; respectively issuing each unique identification information and the corresponding local payment assets to the corresponding payment end of the user; if the payment certificate sent by the receiving terminal is verified to be legal, transferring the paid digital assets contained in the certificate to an account where the receiving terminal is located from the corresponding local payment assets; when the local payment assets are released, the local payment assets are returned to the digital assets existing in the user account. The method not only can respectively determine and issue the local payment assets to the plurality of payment ends of the same user, but also can enable the plurality of payment ends to share the existing digital assets of the same user account to respectively transfer the local payment assets, and can avoid the loss of the user caused by the release of the local payment assets.

Description

Method, server and system for supporting local payment by multiple payment terminals of same user

[ technical field ] A method for producing a semiconductor device

The invention relates to the technical field of digital assets, in particular to a method, a server and a system for supporting local payment by a plurality of payment terminals of the same user.

[ background of the invention ]

Digital assets refer to assets that exist in the form of electronic data, such as virtual assets, digital currency, electronic currency, and the like. In the application process of the digital assets, the local payment of the digital assets from a payment end to a receiving end is involved, the payment end (namely a digital asset holder) locally stores the digital assets issued by a server end in advance, when the local payment is carried out, the payment end obtains the digital assets to be paid from the locally stored digital assets and transmits the digital assets to be paid to the receiving end (namely a digital asset receiver) through local communication, and therefore the receiving end can obtain the digital assets to be paid.

The inventor finds that in the implementation process of local payment of digital assets, one user may have multiple payment ends, and therefore, how to enable the multiple payment ends of the same user to pay according to the locally stored digital assets is a technical problem to be solved.

It is important to note that the above background information is only used to enhance an understanding of the background of the present invention and, thus, may include prior art information that does not constitute a part of the present disclosure as known to one of ordinary skill in the art.

[ summary of the invention ]

The main purpose of the present invention is to provide a method, a server and a system for supporting local payment by multiple payment terminals of the same user, so as to solve at least to some extent one or more technical problems caused by the limitations and drawbacks of the related art, including the following technical solutions:

in a first aspect, a method for supporting local payment by multiple payment terminals of the same user is provided, and applied to a server, the method includes:

for any user with a plurality of payment terminals, setting a plurality of unique identification information under a user account of the user, wherein the user account can be determined according to the unique identification information respectively, and establishing corresponding local payment assets for each unique identification information in the unique identification information respectively, wherein each corresponding local payment asset is transferred from existing digital assets of the user account, and wherein setting first unique identification information under the user account, establishing a corresponding relation between the first unique identification information and a first local payment asset, setting second unique identification information under the user account, and establishing a corresponding relation between the second unique identification information and a second local payment asset;

issuing each unique identification information and the corresponding local payment asset to the corresponding payment end of the user respectively, wherein the issuing comprises issuing the first unique identification information and the first local payment asset to a first payment end, and issuing the second unique identification information and the second local payment asset to a second payment end;

when a payment certificate sent by a receiving terminal is received, the payment certificate comprises unique identification information and paid digital assets, the payment certificate is verified, if the payment certificate is verified to be legal, the paid digital assets are transferred to an account where the receiving terminal is located from corresponding local payment assets, and the corresponding local payment assets are the local payment assets corresponding to the included unique identification information;

and when the local payment asset corresponding to the certain unique identification information is released, returning the corresponding local payment asset to the existing digital asset of the user account to which the certain unique identification information belongs.

Preferably, the unique identification information includes:

payment terminal identification information; alternatively, the first and second electrodes may be,

identification information generated by the server and having uniqueness on the server; alternatively, the first and second electrodes may be,

the system mainly comprises account identification information and a unique identifier, wherein the account identification information is the account identification information of the user account, and the unique identifier has uniqueness under the user account.

Preferably, in the local payment asset respectively corresponding to each unique identification information in the plurality of unique identification information, the local payment asset corresponding to any unique identification information includes:

the digital assets are digital assets in a balance form, a specified amount is subtracted from the balance of the user account, and the specified amount is set as the local payment assets corresponding to any unique identification information; alternatively, the first and second electrodes may be,

the digital assets are digital assets in a balance form, digital assets with a specified limit are transferred from the associated account bound by the user account, and the specified limit is set as local payment assets corresponding to any unique identification information; alternatively, the first and second electrodes may be,

the digital assets are digital assets in a character string form, and digital assets with specified limits are set as local payment assets corresponding to any unique identification information from the existing digital assets of the user account; alternatively, the first and second electrodes may be,

the digital assets are digital assets in a character string form, the user account further comprises digital assets in a balance form, a specified amount is subtracted from the balance of the user account, or the associated account bound by the user account further comprises digital assets in a balance form, the digital assets in a balance form and in the specified amount are transferred from the bound associated account, and the digital assets in a face value or the digital assets with the face value sum in the specified amount are generated to serve as local payment assets corresponding to any one piece of unique identification information.

Preferably, the unique identification information and the local payment assets corresponding to the unique identification information are respectively issued to the payment terminals corresponding to the user, and for issuing the unique identification information of any one of the payment terminals and the local payment assets corresponding to the unique identification information to any one of the payment terminals, the method includes:

sending the unique identification information of any payment terminal and the corresponding local payment asset to any payment terminal; alternatively, the first and second electrodes may be,

the digital asset is in a balance form, and confirmation information is returned to any payment end, wherein the confirmation information represents that the service end determines the unique identification information and the local payment asset of any payment end by using the unique identification information and the local payment amount pre-stored by any payment end, so that after the confirmation information is received by any payment end, the any payment end uses the pre-stored unique identification information as the unique identification information issued by the service end, and the any payment end uses the pre-stored local payment amount as the local payment asset issued by the service end; alternatively, the first and second electrodes may be,

the method comprises the steps that the digital asset is in a balance form, unique identification information of any payment end is sent to any payment end, confirmation information is returned to any payment end, the confirmation information represents that the server end determines local payment assets of any payment end according to a local payment amount pre-stored by any payment end, and therefore after the confirmation information is received by any payment end, the any payment end takes the pre-stored local payment amount as the local payment assets issued by the server end; alternatively, the first and second electrodes may be,

and sending the corresponding local payment asset to any payment terminal, and returning confirmation information to any payment terminal, wherein the confirmation information represents that the server terminal uses the unique identification information pre-stored by any payment terminal as the unique identification information of any payment terminal, so that after the payment terminal receives the confirmation information, the payment terminal uses the pre-stored unique identification information as the unique identification information issued by the server terminal.

Preferably, the verifying the payment credential further comprises:

if the corresponding user account is not determined according to the included unique identification information, determining that the payment voucher is illegal; and/or the first and/or second light sources,

and if the corresponding local payment asset is not acquired according to the included unique identification information, determining that the payment voucher is illegal.

Preferably, the transferring the paid digital assets from the corresponding local payment assets to the account where the receiving end is located includes:

the digital assets are digital assets in a balance form, the paid digital assets are subtracted from the corresponding local payment assets, and the paid digital assets are added into the balance of the account where the receiving end is located, or the paid digital assets are transferred to an associated account bound with the account where the receiving end is located; alternatively, the first and second electrodes may be,

the digital assets are digital assets in a character string form, and the paid digital assets in the corresponding local payment assets are changed into digital assets under the account where the receiving end is located.

Preferably, the transferring the paid digital assets from the corresponding local payment assets to the account where the receiving end is located further comprises:

determining the account of the receiving terminal according to account identification information of the account of the receiving terminal included in the payment voucher or according to account identification information of the payment voucher sending terminal; and/or the first and/or second light sources,

if the account where the receiving end is located belongs to accounts on other service ends, the service end transfers the paid digital assets to the other service ends from the corresponding local payment assets, so that the other service ends transfer the paid digital assets into the account where the receiving end is located.

Preferably, the returning the corresponding local payment asset to the existing digital asset of the user account to which the certain unique identification information belongs includes:

the digital assets are digital assets in a balance form, corresponding local payment assets are added to the balance of the user account to which the certain unique identification information belongs, or the corresponding local payment assets are transferred to the associated account bound with the user account to which the certain unique identification information belongs; alternatively, the first and second electrodes may be,

the digital assets are digital assets in a character string form, and the corresponding local payment assets are set as the existing digital assets under the user account to which the certain unique identification information belongs; alternatively, the first and second electrodes may be,

the digital assets are digital assets in a character string form, the user account to which the certain unique identification information belongs is also used for digital assets in a balance form, a quota which is equal to the corresponding local payment asset face value is added in the balance of the user account to which the certain unique identification information belongs, or the user account to which the certain unique identification information belongs is also bound with an associated account which is used for the digital assets in the balance form, and then the digital assets in the balance form and in the quota which is equal to the corresponding local payment asset face value are transferred into the bound associated account.

Preferably, the determining method of the user account to which the certain unique identification information belongs includes:

if the certain unique identification information is account identification information, the user account to which the certain unique identification information belongs is a user account determined by the certain unique identification information; alternatively, the first and second electrodes may be,

if the certain unique identification information comprises account identification information, the user account to which the certain unique identification information belongs is the user account determined by the account identification information; alternatively, the first and second electrodes may be,

and if the certain unique identification information is associated with the account identification information, acquiring the associated account identification information according to the certain unique identification information, wherein the user account to which the certain unique identification information belongs is the user account determined by the associated account identification information.

Preferably, the method further comprises:

and respectively associating each unique identification information with corresponding payment terminal information, wherein the association of the first unique identification information with the payment terminal information of the first payment terminal and the association of the second unique identification information with the payment terminal information of the second payment terminal are included.

In a second aspect, a method for supporting local payment by multiple payment terminals of the same user is provided, which is applied to the payment terminals, and the method includes:

receiving unique identification information and local payment assets issued by a server, and locally storing the unique identification information and the local payment assets;

when local payment is carried out, deducting digital assets of local payment at this time from the local payment assets stored locally, and generating payment credentials, wherein the payment credentials comprise the unique identification information and the paid digital assets;

and transmitting the payment certificate to a receiving end through local communication.

Preferably, the receiving the unique identification information and the local payment asset issued by the server, and locally storing the unique identification information and the local payment asset includes:

receiving and locally storing the unique identification information and the local payment assets sent by the server; alternatively, the first and second electrodes may be,

the local payment asset is a digital asset in a balance form, confirmation information returned by the server is received, the confirmation information represents that the server determines the unique identification information of the payment terminal and the local payment asset by using the unique identification information and the local payment amount pre-stored by the payment terminal, the pre-stored unique identification information is used as the locally stored unique identification information, and the pre-stored local payment amount is used as the locally stored local payment asset; alternatively, the first and second electrodes may be,

the local payment assets are digital assets in a balance form, unique identification information sent by the server side is received and locally stored, and confirmation information returned by the server side is received, wherein the confirmation information represents that the server side determines the local payment assets of the payment side according to a local payment amount pre-stored by the payment side, and then the payment side takes the pre-stored local payment amount as the locally stored local payment assets; alternatively, the first and second electrodes may be,

receiving and locally storing local payment assets sent by the server, and receiving confirmation information returned by the server, wherein the confirmation information represents that the server determines the unique identification information of the payment terminal by the unique identification information pre-stored by the payment terminal, and then the payment terminal takes the pre-stored unique identification information as the locally stored unique identification information.

Preferably, the deducting the digital asset of the local payment of this time from the local payment asset stored locally comprises:

the local payment asset is a digital asset in a balance form, and the locally stored local payment asset is updated to be a balance obtained by subtracting the paid digital asset from the local payment asset before updating; alternatively, the first and second electrodes may be,

the local payment assets are digital assets in a character string form, and the paid digital assets are changed to be unavailable from the local payment assets stored locally.

In a third aspect, a method for supporting local payment by multiple payment terminals of the same user is provided, which is applied to a receiving terminal, and the method includes:

receiving a payment certificate transmitted by a payment terminal through local communication, wherein the payment certificate comprises unique identification information and paid digital assets;

and sending the payment certificate to a server side so that the server side transfers the digital assets according to the payment certificate.

Preferably, after receiving the payment credential transmitted by the payment terminal through local communication, and before sending the payment credential to the service terminal, the method further includes:

and verifying the payment certificate, and after verifying that the payment certificate is legal, determining that the payment of the payment terminal is successful.

Preferably, the sending the payment credential to the server includes:

the receiving end establishes network connection with the server end, and the receiving end sends the payment certificate to the server end through a network; alternatively, the first and second electrodes may be,

and the receiving end synchronizes the payment certificate to the intermediate equipment so that the intermediate equipment sends the payment certificate to the server end through the network.

In a fourth aspect, a server device includes a processor and a memory, where the processor is configured to execute a program stored in the memory, and the program executes to perform the method according to the first aspect.

A payment end device comprising a processor, a memory, the processor being configured to execute a program stored in the memory, the program when executed performing a method comprising the second aspect as described above.

A sink device comprising a processor and a memory, the processor being configured to execute a program stored in the memory, the program executing the method according to the third aspect.

A chip comprising a processor for calling and running a computer program from a memory to cause a device in which the chip is installed to perform a method as described in the second aspect above, or to cause a device in which the chip is installed to perform a method as described in the third aspect above.

A storage medium having stored therein a program for implementing the method of the first aspect as described above, or a program for implementing the method of the second aspect as described above, or a program for implementing the method of the third aspect as described above.

In a fifth aspect, a system includes a server device, a payment device, and a receiving device, where the server device includes the server device as described in the fourth aspect, the payment device includes the payment device as described in the fourth aspect, and the receiving device includes the receiving device as described in the fourth aspect.

In summary, the technical effects brought by the technical solution provided by the present invention at least include: firstly, the server can respectively determine and issue local payment assets to a plurality of payment terminals of the same user, namely the plurality of payment terminals of the same user can respectively carry out local payment according to the local payment assets on the respective payment terminals; secondly, a plurality of payment ends of the same user can share the digital assets under the account of the same user to transfer local payment assets, so that the condition that the account is set for each payment end and the condition that the digital assets are set for the accounts set for each payment end is avoided; thirdly, when the local payment assets are released, the local payment assets can be returned to the user account to which the local payment assets belong, so that the loss of the local payment assets to the user is avoided; fourthly, the service end can respectively acquire the use conditions of the local payment assets of the plurality of payment ends under the same user, including the balance or the surplus value of the local payment assets of each payment end, deduction records and the like.

[ description of the drawings ]

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.

FIG. 1 is a schematic block diagram of an implementation environment in accordance with the present invention;

FIG. 2 is a flow chart of a first embodiment of a method for supporting local payment by multiple payment terminals of the same user;

FIG. 3 is a flow chart of a second embodiment of a method for supporting local payment by multiple payment terminals of the same user;

FIG. 4 is a flow chart of a third embodiment of a method for supporting local payment by multiple payment terminals of the same user;

fig. 5 is a flowchart of a fourth embodiment of a method for supporting local payment by multiple payment terminals of the same user.

The implementation, functional features and advantages of the objects of the present invention will be further explained with reference to the accompanying drawings.

[ detailed description ] embodiments

In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

Description of an embodiment

Referring to fig. 1, a schematic diagram of an implementation environment according to the present invention is shown. The implementation environment comprises a payment end, a receiving end and a service end, wherein:

the payment end: a payment end (e.g., a first payment end or a second payment end as shown in fig. 1) of the digital asset is used to make a local payment to the receiving end. The payment terminal can be a software program, such as a payment client terminal program; the mobile terminal device may also be a device implemented by a combination of software and hardware, for example, the mobile terminal device may be a user terminal device such as a smart phone, a smart television, a tablet computer, and a notebook computer, or may be a wearable terminal device such as a smart watch and a smart bracelet, or may be another device such as a chip card and a hardware wallet.

Receiving end: and the receiving end (such as the first receiving end or the second receiving end shown in the figure 1) of the digital asset is used for receiving the local payment of the payment end and requesting the transfer of the digital asset to be completed from the service end according to the payment certificate provided by the payment end. The receiving end may be a software program, or may be a device implemented by a combination of software and hardware, for example, the receiving end may be a device such as a smart phone, a point-of-sale (POS) terminal, a scanning gun, a code reader, a PC (personal computer), a server, or may be a terminal device such as a smart television, a tablet computer, a notebook computer, a smart watch, a smart bracelet, or may be another device such as a chip card, a hardware wallet, or the like.

The server side: the server side of the digital assets is used for providing the digital assets for local payment to the payment side, providing the digital assets transfer service to the receiving side, and finishing the transfer of the digital assets at the server side according to the payment certificate transmitted by the receiving side. In practical implementation, the service end may be a registration center, a payment center, or the like for providing digital asset services. The server may be a physical or logical server, or a cloud server, or two or more servers sharing different responsibilities cooperate with each other to implement each function of the server in the embodiments of the present specification.

The information transmission between the payment end and the receiving end is realized through local communication, and the local communication is relative to a communication mode with a digital asset service end, that is, the payment end and the receiving end do not need to pass through the digital asset service end to realize mutual information transmission, and for example, the method can include a local area network or a near field communication mode, wherein the near field communication includes but is not limited to a communication mode through bluetooth, infrared rays, NFC, WIFI, sound waves, BLE (low power consumption bluetooth) or graphic codes. For example, in an environment where the payment end and the receiving end cannot communicate with the internet in real time, a local area network is established in the environment, the payment end and the receiving end are accessed to the local area network, and the payment end and the receiving end communicate with each other through the local area network; for another example, the payment end and the receiving end establish a bluetooth channel through bluetooth pairing to realize near field communication; for another example, the payment end and the receiving end are induced by an NFC antenna to realize near field communication; for example, one of the payment end or the receiving end encodes the information to be transmitted to generate a graphic code, and the other end scans and analyzes the graphic code to obtain the information to be transmitted, so that the short-distance communication between the payment end and the receiving end is realized through the graphic code, which can be a two-dimensional code or a bar code, or other graphics capable of obtaining the information thereof through scanning and decoding.

The information transmission between the payment end and the service end can be realized by establishing network connection between the payment end and the service end, and the network can be the internet or a special network; the payment end can also realize indirect information transfer with the server end through the intermediate device, for example, the intermediate device is a front-end processor with an NFC function, the payment end and the intermediate device perform information transfer through NFC communication, and the intermediate device and the server end perform information transfer through a private network, so that the payment end and the server end perform information transfer.

The information transmission between the receiving end and the server end can be realized by establishing network connection between the receiving end and the server end, and the network can be the internet or a special network; or the receiving end can realize indirect information transmission with the service end through the intermediate equipment.

It should be noted that the local payment in the embodiments of the present invention refers to a payment method in which a payment terminal transmits locally stored digital assets to a receiving terminal for payment through local communication, and this is also described in the background art.

Those skilled in the art will appreciate that the implementation environment architecture shown in fig. 1, as well as the embodiments of the present invention, may enable the local payment of digital assets by the payment end and the receiving end when in a dual online state, or/and a single offline state, or/and a dual offline state. It is understood that the dual online status referred to herein refers to an application scenario where both the payment end and the receiving end are able to communicate with the digital asset server in real time. It is understood that the isolated state referred to herein refers to an application scenario in which only one of the payment end and the receiving end is capable of real-time communication with the digital asset server. It can be understood that the dual offline state referred to herein is an application scenario in which neither the payment end nor the receiving end can perform real-time communication with the digital asset server, that is, both the payment end nor the receiving end are offline with respect to the digital asset server, for example, when the payment end and the receiving end are in an environment with poor network condition or without network requirement, such as a traveling airplane, a remote mountain area or a public sea ship or an underground shopping mall without network signal coverage, a large dining hall with tens of thousands of people eating at the same time and causing network payment congestion, a communication network or a digital asset server failing, and the like, both the payment end and the receiving end cannot perform real-time communication with the digital asset server, and thus are in the dual offline state. It will also be appreciated that as digital asset transactions advance rapidly in the areas of finance, payment, etc., such as pay-bank, WeChat payments, Central bank digital currency, and various banking payment transactions, there is a need and a need to implement local payments.

It will be appreciated that in a practical implementation environment, a plurality or even a large number of users and sinks may be included, wherein each user may have a plurality of payouts. For convenience of illustration, fig. 1 only shows the first payment end and the second payment end of one user, and also only shows the local communication relationship between the first payment end and the first receiving end, and between the second payment end and the second receiving end, in an actual implementation environment, the first payment end may also perform local communication and local payment to the second receiving end or other receiving ends, and the second payment end may also perform local communication and local payment to the first receiving end or other receiving ends. For a terminal device, it may be used only as a payment end or a receiving end, or may be used as both a payment end and a receiving end.

It should be noted that the implementation environment configuration shown in fig. 1 is not limited to the implementation environment, and may include more or less components than those shown, or some components may be combined, or a different arrangement of components may be used, as will be appreciated by those skilled in the art. The implementation environment configuration shown in fig. 1 is only for enhancing understanding of the present technology and thus may include prior art information that does not constitute a known art to those of ordinary skill in the art.

Second, embodiment one of the method for supporting local payment by a plurality of payment terminals of the same user

Referring to fig. 2, a flowchart of a first embodiment of a method for supporting local payment by multiple payment terminals of the same user according to the present invention is shown. The embodiment is exemplified by applying the method to the server in the implementation environment shown in fig. 1, and the method may include:

step 201, for any user with multiple payment terminals, setting multiple unique identification information under a user account of the user, wherein the user account can be determined according to the multiple unique identification information, respectively, and establishing corresponding local payment assets for each unique identification information in the multiple unique identification information, wherein each corresponding local payment asset is transferred from existing digital assets of the user account, and wherein setting first unique identification information under the user account, establishing a corresponding relation between the first unique identification information and a first local payment asset, and setting second unique identification information under the user account, and establishing a corresponding relation between the second unique identification information and a second local payment asset.

For any user with multiple payment ends, namely one or more users with multiple payment ends to support local payment, taking one of the users as an example, respectively determining unique identification information for the multiple payment ends of the user, setting the respectively determined multiple unique identification information under a user account of the user, enabling the user account to be respectively determined according to the multiple unique identification information, and respectively establishing corresponding local payment assets for each unique identification information in the multiple unique identification information, namely establishing corresponding local payment assets for each unique identification information respectively, and transferring each corresponding local payment asset from existing digital assets of the user account. For example, taking the user has a first payment end and a second payment end as an example, for the first payment end, determining unique identification information (i.e., first unique identification information) of the first payment end, and transferring local payment assets (i.e., first local payment assets) for the first payment end from existing digital assets of the user account, setting the first unique identification information under the user account, and establishing a corresponding relationship between the first unique identification information and the first local payment assets; for the second payment terminal, determining unique identification information (namely second unique identification information) of the second payment terminal, transferring local payment assets (namely second local payment assets) used for the second payment terminal from existing digital assets of the user account, setting the second unique identification information under the user account, and establishing a corresponding relation between the second unique identification information and the second local payment assets. Similarly, if the user has a third payment end, a fourth payment end, and the like, third unique identification information may be set under the user account, and a corresponding relationship between the third unique identification information and a third local payment asset is established; setting fourth unique identification information under the user account, establishing a corresponding relation between the fourth unique identification information and a fourth local payment asset, and the like; and so on, and will not be described in detail herein.

It is to be understood that a plurality of embodiments of the present invention refers to two or more cases. In an actual application scenario, the user in the embodiment of the present invention may be a natural person user, an enterprise user, a business user, or the like, and the embodiment of the present invention is not limited.

The unique identification information may be determined in a variety of ways, and specifically may include:

for example, the payment side identification information is used as the unique identification information, and the payment side identification information is identification information for identifying the payment side, and may be a terminal device identifier, a chip card identifier, a mobile phone number, a sub-account number, a digital certificate, a public key, an address generated based on the public key, or other information that can be used for uniquely identifying the payment side.

For another example, the unique identification information is identification information generated by the server and having uniqueness on the server, that is, the unique identification information has uniqueness in the unique identification information on the server, and it can also be understood that a plurality of or even a large number of user accounts are associated with unique identification information on the server, and the generated unique identification information has uniqueness in the unique identification information. For example, the server generates the unique identification information in an increasing order, so that it can be ensured that the generated unique identification information is larger than the previously generated unique identification information, and the unique identification information has uniqueness on the server; for another example, the server generates unique identification information according to the current system time of the server, the time is accurate to the second level, and the unique identification information generated this time and the unique identification information generated last time are ensured to be generated at least more than 1 second apart, so that the generated unique identification information can be ensured to be larger than the unique identification information generated before, and the generated unique identification information has uniqueness at the server; for example, the server generates random information, compares the random information with all current unique identification information, and if the comparison result shows that the same information exists, regenerates the random information and performs the comparison again until the comparison does not have the same information, and determines that the random information is the unique identification information generated this time.

For example, the unique identification information mainly includes account identification information of the user account and a unique identifier that is unique under the user account. For example, account identification information (e.g., a user account number of the user account, user identity information of the user account, payment terminal identification information, etc.) for identifying the user account and a unique identifier form the unique identification information, so that the user account can be identified according to the account identification information, and the corresponding local payment asset can be acquired under the user account according to the unique identifier.

And transferring the local payment assets corresponding to each piece of unique identification information from the existing digital assets of the user account. The digital assets already in the user account are typically digital assets that are currently available under the user account or its associated account and that are not set for local payment. The server transfers the local payment assets from the existing digital assets of the user account, or transfers the appointed digital assets from the existing digital assets of the user account into the digital assets for local payment, including setting the appointed digital assets as the digital assets for local payment.

The server transfers the designated digital assets from the existing digital assets of the user account as local payment assets, and taking the case that any unique identification information is transferred to the corresponding local payment assets, according to the type of the digital assets, corresponding implementation manners can be adopted, for example:

in a first transfer mode, for example, the digital asset is in a form of a balance, a specified amount may be subtracted from the balance of the user account, and the specified amount is set as the local payment asset corresponding to any unique identification information. For example, taking the balance of the user account as 3000 and the specified amount as 1000 as an example, after subtracting 1000 from the balance of the user account, the balance is 2000, and a corresponding relationship between any piece of unique identification information and 1000 is established, where the corresponding relationship represents that 1000 is a local payment asset corresponding to any piece of unique identification information.

And in a second transfer mode, taking the digital asset as a balance form as an example, the digital asset with a specified limit can be transferred from the associated account bound by the user account, and the specified limit is set as the local payment asset corresponding to any unique identification information. For example, if the server is a third-party payment platform (for example, a payment platform similar to a pay bank or a wechat payment), and the specified amount is 1000, the server transfers 1000 from a bank account bound to the user account, and establishes a corresponding relationship between any unique identification information and 1000, where the corresponding relationship represents that 1000 is a local payment asset corresponding to any unique identification information.

And a third scratching mode, taking the digital assets in the form of character strings as an example, each different encryption character string respectively represents the corresponding digital asset, and the server sets the digital assets with the specified quota from the existing digital assets of the user account to be used for local payment. Taking digital currency as an example, each different encryption character string represents corresponding digital currency, taking the specified quota as 1000 as an example, the server selects an encryption character string with a denomination of 1000 from existing digital assets in the user account, or selects a plurality of encryption character strings with a denomination sum of 1000, and establishes a corresponding relationship between any unique identification information and the encryption character string with the denomination of 1000 or the plurality of encryption character strings with the denomination sum of 1000, so as to represent that the local payment asset corresponding to any unique identification information is the encryption character string with the denomination of 1000 or the plurality of encryption character strings with the denomination sum of 1000.

And a fourth transfer mode, taking the digital asset in the form of a character string as an example, if the digital asset in the form of a balance is further included in the user account, subtracting a specified amount from the balance of the user account, or if the digital asset in the form of a balance is further included in the associated account bound to the user account, transferring the digital asset in the form of a balance and in the specified amount from the associated account bound to the user account, and generating the digital asset with the face value or the sum of the face values in the specified amount as the local payment asset corresponding to any one piece of unique identification information. Taking digital currency as an example, and taking a specified amount as 1000 as an example, for example, the server subtracts the specified amount (i.e. 1000) from the balance of the user account, and generates an encrypted character string with a face value of 1000 or generates a plurality of encrypted character strings with a sum of face values of 1000 as a local payment asset corresponding to any unique identification information; for another example, the server transfers 1000 from a bank account bound to the user account, and generates an encrypted character string with a face value of 1000 or generates a plurality of encrypted character strings with a face value sum of 1000 as the local payment asset corresponding to any one piece of unique identification information.

It can be understood that, in the above-mentioned manner of transferring by taking the digital asset as the digital asset in the form of balance, the transferred local payment asset is correspondingly also the digital asset in the form of balance; in the above-mentioned manner of transferring digital assets in the form of character strings, the transferred local payment assets are correspondingly digital assets in the form of character strings.

Setting a plurality of unique identification information under the user account of the user, and respectively establishing corresponding local payment assets for each unique identification information in the plurality of unique identification information, wherein various implementation modes can be provided:

as an example, table 1 shows an implementation manner, in the User account table, both the first unique identification information (User1a) and the second unique identification information (User1b) are account identification information of the User account, that is, the first unique identification information (User1a) and the second unique identification information (User1b) can be used to identify the User account, including acquiring an existing asset (2000) of the User account, and the like, the local payment asset corresponding to the first unique identification information (User1a) is a first local payment asset (1000), and the local payment asset corresponding to the second unique identification information (User1b) is a second local payment asset (1000).

It is understood that the existing asset in the user account table refers to the balance of the existing digital asset of the user account, and the first local payment asset and the second local payment asset refer to the local payment asset transferred from the existing digital asset of the user account, or vice versa, if the local payment asset is transferred in the above transfer manner one, the balance of the existing digital asset of the user account before transfer is 4000, in which 1000 is transferred as the first local payment asset, and 1000 is transferred as the second local payment asset, so that the balance of the existing digital asset of the user account after transfer is 2000, that is, the existing asset of the user account table is 2000. The following example two and example three are the same or similar and will not be described again.

Table 1: user account table

First unique identification information	First local payment asset	Second unique identification information	Second local payment asset	Existing assets
					User1a	1000	User1b	1000	2000

Example two, table 2 shows another embodiment, in the User account table, the User account (User1) is account identification information of the User account, i.e. the User account (User1) can be used to identify the User account, including acquiring existing assets (2000) of the User account; the local payment asset corresponding to the first unique identifier (No1) is a first local payment asset (1000), the local payment asset corresponding to the second unique identifier (No1) is a second local payment asset (1000), in practical application, the User account (User1) and the first unique identifier (No1) form first unique identification information, and the User account (User1) and the second unique identifier (No1) form second unique identification information.

Table 2: another user account table

User account	First unique identification	First local payment asset	Second unique identifier	Second local payment asset	Existing assets
						User1	No1	1000	No2	1000	2000

Third, table 3 and table 4 show another embodiment, in table 3, the User account number (User1) is account identification information of the User account, i.e. the User account number (User1) can be used for identifying the User account, including acquiring an existing asset (2000) of the User account, etc.; meanwhile, in table 4, the local payment asset corresponding to the first unique identification information (id1) is 1000 and is associated with the User account (User1), i.e. can be associated with the User account (User1) according to the first unique identification information (id 1); the second unique identification information (id2) corresponds to a local payment asset of 1000 and is associated with the User account (User1), i.e. according to the second unique identification information (id2) can be associated to the User account (User 1).

Table 3: another user account table (1)

User account	Existing assets
		User1	2000

Table 4: another user account table (2)

Unique identification information	Local payment assets	User account
			id1	1000	User1
id2	1000	User1

As can be seen from the above-mentioned determined unique identification information and examples, a plurality of pieces of unique identification information are set under the user account, so that the user account can be determined according to the plurality of pieces of unique identification information, respectively, as shown in the above-mentioned example one, wherein the unique identification information is the account identification information of the user account, so that the user account and the existing asset set under the user account can be determined according to the unique identification information; as shown in the second example, the unique identification information is information including account identification information of the user account, so that the user account and the existing assets set under the user account can be determined according to the account identification information included in the unique identification information; as shown in the third example, the unique identification information is associated with the account identification information of the user account, so that the associated account identification information can be obtained through the unique identification information, and the user account and the existing assets set under the user account can be determined according to the associated account identification information. It is to be understood that the payment-side identification information, or the identification information generated by the server and having uniqueness on the server, or the like, as the unique identification information, may be associated with the account identification information by referring to the first example or the third example.

It is understood that, for the existing asset (2000) and the local payment asset (1000) in the above examples one to three, the digital asset in the form of a balance is exemplified, wherein 2000 and 1000 respectively represent corresponding balances; similarly, in the practical application process, if the digital asset is in the form of a character string, the existing asset is an encrypted character string with a face value of 2000 or a plurality of encrypted character strings with a face value of 2000 in total, and the local payment asset is an encrypted character string with a face value of 1000 or a plurality of encrypted character strings with a face value of 1000 in total. From this, it can be understood that the encrypted string with the face value of 2000 (or 1000) or the plurality of encrypted strings with the face value of 2000 (or 1000) in total are digital assets under the user account, and it can also be understood that the owner of the encrypted strings is the user account.

It can be understood that, in addition to the above examples one to three, in an actual implementation process, there may be more implementation manners, and a main function of the implementation manners is that, for the unique identification information respectively determined for the plurality of payment terminals of the user, the user account may be respectively determined according to each unique identification information, and the local payment asset corresponding to each unique identification information may be obtained.

It should be noted that, as described above, setting a plurality of unique identification information under the user account is not limited to setting a plurality of unique identification information under the user account at the same time, and specifically, the server allows setting a plurality of different unique identification information under the user account, and for any payment terminal of the user, the server may set the unique identification information for the payment terminal under the user account and establish a local payment asset corresponding to the unique identification information according to a request of the payment terminal, a request of an intermediate device, a background management instruction, a database operation instruction, or the like.

Step 202, each unique identification information and the corresponding local payment asset are respectively issued to the corresponding payment end of the user, wherein the issuing of the first unique identification information and the first local payment asset to the first payment end is included, and the issuing of the second unique identification information and the second local payment asset to the second payment end is included.

Issuing each unique identification information of the plurality of unique identification information and the local payment asset corresponding to the unique identification information to the payment terminal corresponding to the user, or may be understood as that, for any payment terminal of the payment terminals corresponding to the user, the unique identification information of the payment terminal and the local payment asset corresponding to the unique identification information are issued to the payment terminal, for example, in the example in the step 201, the first unique identification information and the first local payment asset are issued to the first payment terminal, and the second unique identification information and the second local payment asset are issued to the second payment terminal.

Issuing each unique identification information and the local payment asset corresponding to the unique identification information to the payment terminal corresponding to the user, wherein in a specific implementation manner, for example, issuing the unique identification information of any payment terminal and the local payment asset corresponding to the unique identification information to the any payment terminal may specifically include:

for example, the server sends the unique identification information of any payment terminal and the local payment asset corresponding to the unique identification information to any payment terminal, so that any payment terminal receives the unique identification information and the local payment asset sent by the server.

For another example, if the digital asset is a digital asset in a balance form, and if the server is the unique identification information of any payment terminal and the local payment asset determined according to the unique identification information and the local payment amount pre-stored by any payment terminal, the server may return confirmation information to any payment terminal, where the confirmation information represents that the server has determined the unique identification information and the local payment asset according to the unique identification information and the local payment amount pre-stored by any payment terminal, so that after the any payment terminal receives the confirmation information, the any payment terminal uses the unique identification information pre-stored as the unique identification information issued by the server, and uses the local payment amount pre-stored as the local payment asset issued by the server. It can be understood that the unique identification information pre-stored for any one of the payers also includes preset unique identification information, for example, preset payer identification information such as a terminal device identifier of the payer, a chip card identifier, and the like.

For another example, the server sends the unique identification information of any payment terminal to any payment terminal, so that any payment terminal receives the unique identification information sent by the server; and if the digital asset is in a balance form, the server returns confirmation information to any payment terminal, the confirmation information represents that the server already determines local payment assets according to local payment amount pre-stored by any payment terminal, so that after any payment terminal receives the confirmation information, the any payment terminal takes the pre-stored local payment amount as the local payment assets issued by the server, for example, the any payment terminal sends an operation request for obtaining the local payment assets to the server, the local payment amount requested in the request is 1000, and the local payment amount (namely 1000) is pre-stored, when the any payment terminal receives the confirmation information returned by the server, the confirmation information represents that the server already determines local payment assets according to the local payment amount pre-stored by any payment terminal, the payment terminal takes the pre-saved local payment amount (i.e. 1000) as the local payment asset (i.e. 1000) issued by the server terminal.

For example, the server sends the local payment asset of any payment terminal to any payment terminal, so that any payment terminal receives the local payment asset sent by the server; and the server returns confirmation information to any payment terminal, wherein the confirmation information represents that the server determines unique identification information by the unique identification information prestored by any payment terminal, so that after any payment terminal receives the confirmation information, the any payment terminal takes the prestored unique identification information as the unique identification information issued by the server.

It can be understood that the embodiment of the present invention can support local payment by a plurality of payment terminals of one, a plurality of even a large number of users, and therefore, for the one, the plurality of even a large number of users, the

above steps

201 and 202 can be referred to, so that the unique identification information and the corresponding local payment asset can be respectively determined and issued to the plurality of payment terminals of each user.

Step 203, when a payment certificate sent by a receiving terminal is received, wherein the payment certificate comprises unique identification information and paid digital assets, the payment certificate is verified, if the payment certificate is verified to be legal, the paid digital assets are transferred to an account where the receiving terminal is located from corresponding local payment assets, and the corresponding local payment assets are the local payment assets corresponding to the included unique identification information.

When the server receives a payment certificate sent by a receiving end, the payment certificate comprises unique identification information and paid digital assets, the server verifies the payment certificate, if the payment certificate is verified to be legal, the paid digital assets are transferred to an account where the receiving end is located from corresponding local payment assets, and the corresponding local payment assets are the local payment assets corresponding to the included unique identification information. It is to be understood that the included unique identification information refers to the unique identification information included in the payment credentials.

Since the correspondence relationship between the unique identification information and the local payment asset is established in step 201, in this step 203, the corresponding local payment asset can be determined according to the included unique identification information, that is, the corresponding local payment asset in this step 203 is the local payment asset corresponding to the included unique identification information, for example, if the included unique identification information is the first unique identification information, the local payment asset corresponding to the included unique identification information is the first local payment asset, that is, the corresponding local payment asset is the first local payment asset; and if the included unique identification information is the second unique identification information, the local payment asset corresponding to the included unique identification information is the second local payment asset, namely the corresponding local payment asset is the second local payment asset.

The digital assets paid are transferred to the account where the receiving end is located from the corresponding local payment assets, which can also be understood as deducting the digital assets paid from the local payment assets corresponding to the included unique identification information, and adding the digital assets paid to the account where the receiving end is located. It is to be understood that, since the paid digital asset is deducted from the corresponding local payment asset, when none of the paid digital assets is used for deduction, for example, the corresponding local payment asset has been released (for example, deleted, emptied, reset to zero or invalid, etc.), or the balance or remaining value of the corresponding local payment asset is smaller than the paid digital asset, etc., the server may determine that the payment credential is illegal and may not transfer the digital asset.

According to the type of the digital assets, a corresponding scratching and transferring mode can be adopted, and the method specifically comprises the following steps:

taking digital assets in the form of balance as an example, the server subtracts the paid digital assets from the corresponding local payment assets (which may also be understood as updating the corresponding local payment assets to local payment assets before updating but subtracting the paid digital assets), adds the paid digital assets to the balance of the account where the receiving end is located, or transfers the paid digital assets to an associated account bound to the account where the receiving end is located. For example, taking the corresponding local payment asset as 1000, the balance of the account where the receiving end is located as 1000, and the paid digital asset as 100 as an example, after the paid digital asset is transferred to the account where the receiving end is located from the corresponding local payment asset, the corresponding local payment asset is updated to 900 by subtracting 100, and the balance of the account where the receiving end is located is updated to 1100 by adding 100; for another example, if the corresponding local payment asset is 1000 and the paid digital asset is 100, the corresponding local payment asset is updated to 900 by subtracting 100, and the corresponding local payment asset is transferred to 100 in the bank account bound to the account where the receiving end is located. It will be appreciated that a transfer of digital assets may be made if the paid digital assets are not greater than the corresponding local payment assets, and that a transfer of digital assets may not be made otherwise.

Taking digital assets in the form of character strings as an example, the server side changes the paid digital assets in the corresponding local payment assets into digital assets under the account where the receiving end is located. Specifically, the owner of each digital asset is recorded in the server, that is, the corresponding owner is recorded in the encrypted string representing the digital asset in the server, the owner of the paid digital asset is changed to the account where the receiving end is located, that is, the paid digital asset is determined from the corresponding local payment asset (for example, character string matching is performed according to the paid digital asset, or matching is performed according to the number of the paid digital asset, or the like to determine), the owner of the paid digital asset is changed to the account where the receiving end is located, and the paid digital asset is changed to a currently available state (that is, not used for local payment) under the account where the receiving end is located. It is understood that if the paid digital asset cannot be determined from the corresponding local payment asset (e.g. matching fails), then transfer of the digital asset may not be performed, i.e. transfer of the paid digital asset from the corresponding local payment asset to the account of the receiving end is not performed.

It can be understood that the account where the receiving end is located in the embodiment of the present invention may be determined in multiple ways, for example, the payment credential generated by the payment end includes account identification information of the account where the receiving end is located (for example, a user account number of the account where the receiving end is located, user identity information of the account where the receiving end is located, receiving end identification information, and the like), that is, the account identification information is identification information that can be used to identify the account where the receiving end is located, so that the service end may determine the account where the receiving end is located according to the account identification information; for another example, when the server receives the payment credential, the server obtains account identification information (e.g., a user account number, user identity information, receiving end identification information, etc.) of the sender, where the account identification information is identification information that can be used to identify an account where the receiving end is located, and the server determines the account where the receiving end is located according to the account identification information. It can be understood that the receiving end identification information is information for identifying a receiving end, and may be a terminal device identifier, a chip card identifier, a mobile phone number, an account number, a digital certificate, a public key, an address generated based on the public key, or other information that can be used for uniquely identifying the receiving end.

It can be understood that, if the account where the receiving end is located belongs to an account on another server, the server may transfer the paid digital assets from the corresponding local payment assets to the other server, and then transfer the paid digital assets into the account where the receiving end is located by the other server.

The implementation manner of the server verifying the payment credential may include checking whether the data format of the payment credential is valid, verifying authentication information or user information (if related) carried in the payment credential, and the like.

It can be understood that if the corresponding user account is not determined according to the included unique identification information, for example, the included unique identification information is not the account identification information on the server, for example, the included unique identification information does not include the account identification information on the server, for example, the server is not associated with the corresponding account identification information according to the included unique identification information, and the like; or if the corresponding local payment asset is not acquired according to the included unique identification information, the payment voucher is determined to be illegal, and the payment of the digital asset from the corresponding local payment asset to the account where the receiving terminal is located is not executed.

It can be understood that the server may receive the payment credential many times, and after determining that the received payment credential is legal, transfer the digital asset paid in the payment credential to an account where the corresponding receiving end is located from the corresponding local payment asset, where the corresponding local payment asset is the local payment asset corresponding to the unique identification information in the payment credential, and the account where the corresponding receiving end is located is the account where the receiving end is located determined according to the payment credential or the sender thereof.

It will be appreciated that each time a transfer of a digital asset is made from the corresponding local payment asset, the corresponding local payment asset will be correspondingly reduced. Taking digital assets in a form of balance as an example, and taking the corresponding digital assets as local payment assets corresponding to the same unique identification information as an example, after the corresponding local payment assets are 900, if local payment is performed again and the paid digital assets are 200, 200 is subtracted from the corresponding local payment assets, so that the corresponding local payment assets are updated to 700; if a local payment is made again and the digital asset paid is 300, then 300 is subtracted from the corresponding local payment asset and the corresponding local payment asset is updated to 400. For another example, taking a digital asset in a form of a character string as an example, and taking the corresponding digital asset as a local payment asset corresponding to the same unique identification information as an example, after the corresponding local payment asset is an encrypted character string with a face value of 900 or a plurality of encrypted character strings with a face value sum of 900, if local payment is performed again and the face value of the paid digital asset is 200, the corresponding local payment asset is changed into the encrypted character string with a face value of 700 or the plurality of encrypted character strings with a face value sum of 700 after the digital asset with the face value of 200 is transferred to the account where the receiving end is located from the corresponding local payment asset; if local payment is carried out again and the sum of the face values of the paid digital assets is 300, after the digital assets with the sum of the face values of 300 are transferred to the account where the receiving terminal is located from the corresponding local payment assets, the corresponding local payment assets are changed into encryption character strings with the face values of 400 or encryption character strings with the sum of the face values of 400.

In the

above steps

201 and 202, when determining or issuing unique identification information on the server, the unique identification information may be further associated with the payment end information, so that the server can respectively know the usage of the local payment assets of multiple payment ends under the same user, including the balance or the remainder, deduction records, and the like of the local payment assets of each payment end, for example, the first unique identification information is associated with the payment end information (such as the name and/or the type of the first payment end) of the first payment end, the second unique identification information is associated with the payment end information (such as the name and/or the type of the second payment end) of the second payment end, and thus, according to the usage of the first local asset paid corresponding to the first unique identification information, the use condition of the local payment assets on the first payment terminal can be known; and acquiring the use condition of the local payment asset on the second payment end according to the use condition of the second local payment asset corresponding to the second unique identification information.

And 204, when the local payment asset corresponding to the unique identification information is released, returning the corresponding local payment asset to the existing digital asset of the user account to which the unique identification information belongs.

Releasing a local payment asset at the server means changing the local payment asset to be no longer available for local payment, for example, deleting, emptying, resetting to zero or invalidating the local payment asset.

On the server, it may be necessary to release a local payment asset on the server for a variety of reasons, that is, it is necessary to release a local payment asset corresponding to a unique identification information, for example, when the payment terminal logs off, or the payment terminal reaches the validity period of use, or a local payment asset reaches the validity period, or a local payment asset corresponding to a payment terminal needs to be reduced according to actual use needs.

It can be understood that, the local payment asset corresponding to a certain unique identification information is released, where the corresponding local payment asset refers to all or part of the local payment asset corresponding to the certain unique identification information when the local payment asset is released, that is, according to actual needs, all the local payment assets corresponding to the certain unique identification information may be released, or a part of the local payment assets corresponding to the certain unique identification information may be released, and taking the certain unique identification information as the same unique identification information as that illustrated in step 203 as an example, after the multiple transfers of the digital asset described in the example, if the digital asset is not transferred, and taking the digital asset as a digital asset in a balance form as an example, the local payment asset corresponding to the certain unique identification information that is released is 400, or may also be partially released (for example, the corresponding local payment asset that is released is 200, i.e., reduced by 200); taking digital assets in the form of character strings as an example, the local payment assets corresponding to a certain released unique identification information are all or part of the encrypted character strings with the face value of 400 or the encrypted character strings with the face value sum of 400.

When the local payment asset corresponding to a certain unique identification information is released on the server, if the corresponding local payment asset is directly deleted, emptied, reset to zero or made invalid, etc., the corresponding local payment asset is lost, so that the corresponding local payment asset is returned to the existing digital asset of the user account to which the certain unique identification information belongs in step 204, thereby avoiding the loss of the corresponding local payment asset.

Since the plurality of unique identification information may be set under the user account in step 201, so that the user account may be determined according to the plurality of unique identification information, in this step 204, the user account to which the certain unique identification information belongs may be determined according to the certain unique identification information, for example, if the certain unique identification information is the first unique identification information or the second unique identification information in step 201, the user account to which the certain unique identification information belongs should be the user account in step 201, and specifically, determining the user account to which the certain unique identification information belongs may include:

in a first determination mode, if the certain unique identification information is account identification information, the user account to which the certain unique identification information belongs is determined to be the user account determined by the certain unique identification information. As described in the first example of step 201 above, the unique identification information set under the user account may be account identification information, and therefore, if the certain unique identification information is account identification information, it is determined that the user account to which the certain unique identification information belongs is the user account determined by the certain unique identification information.

In a second determination mode, if the certain unique identification information includes account identification information, the user account to which the certain unique identification information belongs is determined as the user account determined by the account identification information. As described in the second example in step 201 above, the unique identification information set under the user account may be identification information mainly composed of account identification information and a unique identifier, and therefore, if the certain unique identification information is identification information mainly composed of account identification information and a unique identifier, the account identification information included in the certain unique identification information is acquired, and the user account to which the certain unique identification information belongs is determined as the user account determined by the account identification information.

And if the certain unique identification information is associated with the account identification information, acquiring the associated account identification information according to the certain unique identification information, wherein the user account to which the certain unique identification information belongs is the user account determined by the associated account identification information. As described in the third example in step 201 above, the unique identification information set under the user account may be associated with the account identification information, so that if the certain unique identification information is associated with the account identification information, the associated account identification information is obtained according to the certain unique identification information, and the user account to which the certain unique identification information belongs is the user account determined by the associated account identification information.

It should be noted that, for the unique identification information in the embodiment of the present invention, the embodiment of the present invention does not limit that it is necessarily a character string information, it may also be information composed of a plurality of pieces of information in common, for example, in the case where the unique identification information is mainly composed of account identification information and a unique identification, the payment voucher comprises the account identification information and the unique identification, the server side determines a user account by obtaining the account identification information, and then obtains the corresponding local payment asset under the user account through the unique identification, therefore, even if the account identification information and the unique identifier do not form character string information, the functions of determining the affiliated user account and acquiring the corresponding local payment asset can be still achieved by acquiring the account identification information and the unique identifier in the payment voucher.

Corresponding to the transfer of the designated digital asset from the existing digital assets of the user account as the local payment asset in step 201, the return of the corresponding local payment asset to the existing digital asset of the user account to which the certain unique identification information belongs may take corresponding embodiments, for example:

returning to the first mode, taking the digital asset in the form of a balance as an example, the corresponding local payment asset may be added to the balance of the user account to which the certain unique identification information belongs. For example, taking the balance of the affiliated user account as 3000 and the corresponding local payment asset as 1000 as an example, after releasing the corresponding local payment asset and returning the corresponding local payment asset to the existing digital asset of the user account to which the certain unique identification information belongs, the balance of the affiliated user account plus 1000 is 3000.

And returning to the second mode, taking the digital asset in the form of balance as an example, the corresponding local payment asset can be transferred into the associated account bound to the user account to which the certain unique identification information belongs. For example, if the server is a third party payment platform (for example, a payment platform similar to a pay treasure or a WeChat payment platform), and if the corresponding local payment asset is 1000, the server transfers 1000 to a bank account bound to the user account when releasing the corresponding local payment asset.

And returning to the third mode, taking the digital asset in the form of a character string as an example, the server sets the corresponding local payment asset as the existing digital asset in the user account to which the certain unique identification information belongs. Taking digital currency as an example, each different encryption character string represents corresponding digital currency, and taking the corresponding local payment asset as an encryption character string with a denomination of 1000 or a plurality of encryption character strings with a denomination of 1000 in total as an example, when the corresponding local payment asset is released, the server changes the encryption character string with the denomination of 1000 or the plurality of encryption character strings with the denomination of 1000 in total from the local payment asset to an existing digital asset, or may be understood as changing the encryption character string with the denomination of 1000 or the plurality of encryption character strings with the denomination of 1000 in total from a state for local payment to a state currently available under a user account to which the certain unique identification information belongs.

And returning to the fourth mode, taking the digital asset in the form of a character string as an example, if the user account to which the certain unique identification information belongs is also used for the digital asset in the form of balance, adding an amount equal to the corresponding local payment asset surface value in the balance of the user account to which the certain unique identification information belongs, or if the user account to which the certain unique identification information belongs is also bound with an associated account for the digital asset in the form of balance, transferring the digital asset in the form of balance and in the amount equal to the corresponding local payment asset surface value into the bound associated account. Taking digital currency as an example, and taking the corresponding local payment asset as an encryption character string with a face value of 1000 or a plurality of encryption character strings with a face value sum of 1000 as an example, when the corresponding local payment asset is released, 1000 is added to the balance of the user account to which the certain unique identification information belongs, or 1000 is transferred into the bank account bound to the user account to which the certain unique identification information belongs.

As can be seen from the above embodiments applied to the server, the technical effects produced by the embodiments of the present invention at least include that, firstly, the server can respectively determine and issue local payment assets to a plurality of payment terminals of the same user, that is, the plurality of payment terminals of the same user can respectively perform local payment according to the local payment assets on the respective payment terminals; secondly, a plurality of payment ends of the same user can share the digital assets under the account of the same user to transfer local payment assets, so that the condition that the account is set for each payment end and the condition that the digital assets are set for the accounts set for each payment end is avoided; thirdly, when the local payment assets are released, the local payment assets can be returned to the user account to which the local payment assets belong, so that the loss of the local payment assets to the user is avoided; fourthly, the service end can respectively acquire the use conditions of the local payment assets of the plurality of payment ends under the same user, including the balance or the surplus value of the local payment assets of each payment end, deduction records and the like.

Third, method embodiment two for multiple payment terminals of the same user to support local payment

Referring to fig. 3, it shows a flowchart of a second embodiment of the method for supporting local payment by multiple payment terminals of the same user according to the present invention. The embodiment is exemplified by applying the method to a payment terminal (such as a first payment terminal or a second payment terminal) in the implementation environment shown in fig. 1, and the method may include:

and 301, receiving the unique identification information and the local payment assets issued by the server, and locally storing the unique identification information and the local payment assets.

In step 202 of the first embodiment, the server issues each unique identification information and the corresponding local payment asset to the corresponding payment end of the user, and correspondingly, in the second embodiment, the explanation is given by taking any one payment end (such as the first payment end or the second payment end) of the corresponding payment ends as an example, that is, for the unique identification information and the local payment asset issued by the server to the payment end (i.e., any one payment end of the corresponding payment ends), the payment end receives the unique identification information and the local payment asset, and locally stores the unique identification information and the local payment asset.

And 302, when local payment is carried out, deducting the digital assets of the local payment at the current time from the local payment assets stored locally, and generating a payment certificate, wherein the unique identification information and the paid digital assets are included in the payment certificate.

When the payment terminal carries out local payment, the payment terminal deducts the digital assets of the local payment at the current time from the local payment assets stored locally and generates payment credentials, and the unique identification information and the digital assets of the payment are included in the payment credentials.

In an actual implementation process, the payment terminal may obtain a payment amount, and deduct the digital asset of the local payment at this time from the local payment asset stored locally according to the payment amount (hereinafter, the digital asset of the local payment at this time is referred to as the paid digital asset). It can be understood that the payment amount refers to the amount of the digital asset to be paid by the payment terminal to the receiving terminal, and the payment amount may be input by the user, may also be transmitted to the payment terminal by the receiving terminal, and may also be input in other manners, which is not limited to this embodiment of the present invention.

Taking digital assets in a form of balance as an example, the payment terminal deducts the digital assets locally paid this time from the locally saved local payment assets, which can also be understood as updating the locally saved local payment assets into the balance after the local payment assets before updating are deducted from the paid digital assets. For example, taking the local payment asset locally stored by the payment terminal in step 301 as 1000 as an example, if the payment amount is 100, the digital asset paid is also 100, after the payment terminal deducts the digital asset paid locally this time from the local payment asset locally stored, the local payment asset locally stored by the payment terminal is updated to 900, and the digital asset paid included in the payment credential is 100.

Taking digital assets in the form of character strings as an example, the payment terminal deducts the digital assets paid locally this time from the locally stored local payment assets, which may also be understood as changing the paid digital assets from the locally stored local payment assets to unavailable, including deleting the paid digital assets or setting the paid digital assets to an invalid state. For example, in the above step 301, taking as an example that the local payment asset locally stored by the payment terminal is an encrypted character string with a face value of 1000 or a plurality of encrypted character strings with a face value of 1000, if the payment amount is 100, the payment terminal determines an encrypted character string with a face value of 100 or a plurality of encrypted character strings with a face value of 100 from the local payment asset locally stored, and changes the encrypted character string with a face value of 100 or the plurality of encrypted character strings with a face value of 100 to be unavailable (for example, deletes the encrypted character string with a face value of 100 or the plurality of encrypted character strings with a face value of 100 or sets the encrypted character strings with a face value of 100 to be in an invalid state, etc.), and the digital asset paid included in the payment certificate is the encrypted character string with a face value of 100 or the plurality of encrypted character strings with a face value of 100, after the above implementation, the local payment asset locally stored by the payment end is changed into an encrypted character string with a face value of 900 or a plurality of encrypted character strings with a face value of 900 in total, or the digital asset locally available for local payment by the payment end may be changed into an encrypted character string with a face value of 900 in total or a plurality of encrypted character strings with a face value of 900 in total.

It is understood that the payment terminal can make a plurality of local payments, and deduct the locally paid digital asset from the locally stored local payment assets each time a local payment is made. For example, taking digital assets in the form of balance as an example, after the local payment assets saved locally is 900, if local payment is made again and the payment amount is 200, then the local payment assets saved locally is updated to 700 if the payment amount is subtracted from the local payment assets saved locally; if a local payment is made again and the payment amount is 300, then the payment amount is subtracted from the local payment asset held locally 300, and the local payment asset held locally is updated to 400. For another example, taking a digital asset in the form of a character string as an example, after the locally-saved local payment asset is an encrypted character string with a face value of 900 or a plurality of encrypted character strings with a face value sum of 900, if local payment is performed again and the payment amount is 200, the encrypted character string with a face value of 200 or the plurality of encrypted character strings with a face value sum of 200 is changed to be unavailable from the locally-saved local payment asset, and the local payment asset locally-saved at the payment end is changed to an encrypted character string with a face value of 700 or a plurality of encrypted character strings with a face value sum of 700; if local payment is carried out again and the payment amount is 300, the encrypted character strings with the face value of 300 or a plurality of encrypted character strings with the face value sum of 300 are changed to be unavailable from the local payment assets stored locally, and the encrypted character strings with the face value sum of 400 or a plurality of encrypted character strings with the face value sum of 400 are changed from the local payment assets stored locally at the payment end.

It can be understood that, since the locally-paid digital asset is deducted from the locally-saved local payment asset when the payment terminal performs local payment, when there is no locally-saved local payment asset in the local payment asset of the payment terminal that can be used for the locally-paid deduction, for example, the locally-saved local payment asset has been released (for example, deleted, cleared, reset to zero or invalid, etc.), or the balance or remaining value of the locally-saved local payment asset is smaller than the payment amount of the local payment, etc., the payment terminal cannot perform local payment, that is, the payment terminal cannot generate payment credentials according to the locally-saved local payment asset.

And 303, transmitting the payment certificate to a receiving end through local communication.

The payment terminal transmits the payment credential to a receiving terminal through local communication, as described in the description of the implementation environment, the payment terminal may transmit the payment credential to the receiving terminal through a local area network, or may transmit the payment credential to the receiving terminal through near field communication methods such as bluetooth, infrared ray, NFC, WIFI, acoustic wave, BLE (low power consumption bluetooth), or graphic code.

In the above embodiment applied to the payment terminal, the payment terminal performs local payment according to the unique identification information and the local payment asset issued by the server, and the generated payment voucher includes the unique identification information, and since the correspondence between the unique identification information and the local payment asset is established at the server, after the server receives the payment voucher, the corresponding local payment asset can be obtained according to the unique identification information, and the transfer of the digital asset from the corresponding local payment asset can be performed according to the payment voucher.

Fourth, method embodiment three for supporting local payment by multiple payment terminals of same user

Referring to fig. 4, a flowchart of a third embodiment of the method for supporting local payment by multiple payment terminals of the same user according to the present invention is shown. The embodiment is exemplified by applying the method to a receiving end (such as a first receiving end or a second receiving end) in the implementation environment shown in fig. 1, and the method may include:

and step 401, receiving a payment certificate transmitted by a payment terminal through local communication, wherein the payment certificate comprises unique identification information and paid digital assets.

In step 303 of the second embodiment, the payment terminal transmits the payment credential to the receiving terminal through local communication, and correspondingly, the third embodiment takes the receiving terminal receiving the payment credential as an example to explain, that is, the receiving terminal receives the payment credential transmitted by the payment terminal through local communication, and the payment credential includes unique identification information and digital assets for payment.

Step 402, optionally, verifying the payment voucher, and after verifying that the payment voucher is legal, determining that the payment is successful.

Optionally, the receiving end verifies the payment credential, and after verifying that the payment credential is legal, it is determined that the payment is successful.

The implementation manner of verifying the payment credential by the receiving end may include checking whether a data format of the payment credential is valid, determining whether the paid digital asset meets a preset requirement, verifying authentication information or user information (if related) carried in the payment credential, and the like.

After the receiving end verifies that the payment voucher is legal, the receiving end determines that the payment of the payment end is successful, and can also understand that the payment is approved. Taking a running airplane as an example, after determining that the payment is successful at the payment terminal, the crew member may provide corresponding goods or services for the passenger who has paid successfully; for another example, when the payment terminal accesses the application server, the payment terminal triggers purchase of a corresponding service (such as shopping, viewing, and the like), and sends the payment credential to the receiving terminal, after the receiving terminal determines that the payment terminal has successfully paid, the receiving terminal feeds back information indicating that the payment is successful to the application server, and the application server determines that the payment terminal has successfully purchased, and provides the corresponding service to the payment terminal.

It is understood that this step is an optional implementation step, and the receiving end may implement this step in an online state or an offline state, so that it may be determined whether the payment is successful or not after the receiving end receives the payment credential and before the payment credential is sent to the service end. It is understood that the online status refers to an application scenario capable of real-time communication with the digital asset server, and the offline status refers to an application scenario incapable of real-time communication with the digital asset server.

And step 403, sending the payment certificate to a server, so that the server transfers the digital assets according to the payment certificate.

And the receiving end sends the payment certificate to the server end. Specifically, a network connection may be established between the receiving end and the service end, and the receiving end directly sends the payment credential to the service end, for example, after an airplane is landed, the receiving end accesses a mobile internet and establishes a network connection with the service end, and the receiving end sends the payment credential to the service end; the receiving end may also send the payment credential to the server indirectly, that is, the receiving end sends the payment credential to the server through an intermediate device (e.g., a collection device such as a collection server), for example, a collection device is deployed on an airplane, the receiving end synchronizes the payment credential to the collection device, after the airplane lands on the ground, the collection device establishes a network connection with the server, and the collection device sends the payment credential to the server; for another example, after the airplane lands on the ground, the receiving end accesses the mobile internet and establishes network connection with a collection server of the airline company, the receiving end synchronizes the payment certificate to the collection server, and the collection server sends the payment certificate to the service end through the network.

It is understood that if the receiving end is the payment credential received in the offline state, the receiving end or the intermediary should be in the online state before the payment credential can be sent to the service end.

It is understood that if the payment credential is verified to be illegal in step 402, the receiving end may not send the payment credential to the service end, so as to avoid the service end from verifying the illegal payment credential; the receiving end may also send the payment credential to the server, so that the server performs further verification or/and audit record and the like.

After the receiving end sends the payment credential to the server end, correspondingly, the server end receives the payment credential sent by the receiving end, verifies the payment credential, and transfers the digital asset according to the payment credential, and the like.

In the embodiment applied to the receiving terminal, the receiving terminal receives the payment certificate transmitted by the payment terminal through local communication and sends the payment certificate to the server, so that the server verifies the payment certificate and transfers the digital assets according to the payment certificate after determining that the payment certificate is legal.

Fifth, method embodiment of supporting local payment by multiple payment terminals of the same user

Referring to fig. 5, a flowchart of a fourth embodiment of the method for supporting local payment by multiple payment terminals of the same user according to the present invention is shown. The embodiment is an embodiment formed by combining the first embodiment, the second embodiment and the third embodiment of the method for supporting local payment by a plurality of payment terminals of the same user. The embodiment is exemplified by applying the method to the implementation environment shown in fig. 1, and is exemplified by implementing a complete process by the server, the payment terminal, and the receiving terminal, where the payment terminal is exemplified by the first payment terminal shown in fig. 1, and the receiving terminal is exemplified by the first receiving terminal shown in fig. 1, and the method may include:

step 501, the server side responds to the operation of the first payment side to obtain a user account where the first payment side is located.

The server triggers the server to start determining the local payment asset for the first payment terminal in response to an operation of determining the local payment asset for the first payment terminal, for example, when the server opens a local payment function for the first payment terminal, or when the first payment terminal sends an operation request for obtaining the local payment asset to the server, or when the first payment terminal performs a specific action (such as user login).

The server acquires a user account where the first payment terminal is located, for example, the server performs user identity authentication on the first payment terminal, so as to acquire the user account where the first payment terminal is located; for another example, the server receives a request, sent by an intermediate device or a background management instruction, for determining a local payment asset for the first payment terminal, where the request includes account identification information, and the account identification information is used to identify a user account where the first payment terminal is located.

Step 502, the service terminal transfers the first local payment asset used for the first payment terminal from the existing digital assets of the user account, and determines first unique identification information.

In the actual implementation process, the local payment amount of the first payment terminal can be determined first, and then the digital asset of the local payment amount is transferred from the existing digital assets of the user account to be used as the local payment asset of the first payment terminal. In order to distinguish the local payment asset of the first payment terminal from the local payment assets of other payment terminals, the local payment asset of the first payment terminal is referred to as a first local payment asset.

The server may determine the local payment amount in various embodiments, and specifically may include:

for example, the server uses a preset amount as the local payment amount, for example, if the preset amount of the server is 1000, the local payment amount is determined to be 1000.

For another example, the server determines the local payment amount according to an amount requested by a payment end, for example, the server receives an operation request for obtaining the local payment amount sent by the first payment end, where the local payment amount requested in the request is 1000, and the server determines that the local payment asset corresponding to the first payment end is 1000.

For example, the server determines the local payment amount according to the payment record or/and credit rating or/and user information of the user account or/and the currently established local payment asset under the user account or/and the payment terminal type and the like. For example, the server determines that the local payment amount of each payment end of the user is 1000 according to the payment record or/and the credit rating or/and the user information of the user account, and then the local payment amount is 1000; for another example, the server divides the payment terminal into corresponding types (for example, a first type, a second type, or the like, or a software type, a hardware type, or the like), and each type sets a corresponding local payment amount; for another example, the server determines that the total local payment amount of the user account is 1000, and if the denomination or value of the local payment asset that has been established for the other payment terminals of the user account on the server is 600, determines that the local payment amount of the first payment terminal is 400.

It is understood that the local payment asset refers to a digital asset used for issuing to the payment terminal for local payment, and the local payment amount refers to an amount used for determining the local payment asset.

It is understood that when the local payment asset is only used for payment when the payment terminal or/and the receiving terminal is in an offline state, the local payment asset may also be referred to as an offline payment asset, that is, a digital asset for offline payment, and accordingly, the local payment amount may also be referred to as an offline payment amount.

The above-mentioned transferring the digital asset of the local payment amount from the existing digital assets of the user account as the local payment asset (i.e. the first local payment asset) of the first payment terminal may adopt a corresponding implementation manner according to the type of the digital asset, and specifically may include:

for example, taking digital assets in the form of balance as an example, the local payment amount is subtracted from the balance of the user account, and the local payment amount is set as the local payment asset corresponding to the first unique identification information.

For another example, taking digital assets in the form of balance as an example, the digital assets of the local payment amount are transferred from the associated account bound by the user account, and the local payment amount is set as the local payment asset corresponding to the first unique identification information.

For another example, taking digital assets in the form of character strings as an example, the digital assets of the local payment amount are set as local payment assets corresponding to the first unique identification information from the existing digital assets of the user account.

For another example, taking digital assets in a form of character strings as an example, if digital assets in a form of balance are further included in the user account, the local payment amount is subtracted from the balance of the user account, or if digital assets in a form of balance are further included in the associated account bound to the user account, digital assets in a form of balance and in a form of the local payment amount are transferred from the associated account bound to the user account, and digital assets with face value or face value sum in a form of the local payment amount are generated as local payment assets corresponding to the first unique identification information.

The server determines first unique identification information so that the first local payment asset can be acquired according to the first unique identification information, for example, payment terminal identification information of the first payment terminal is used as the first unique identification information; for another example, unique identification information is generated on the server as the first unique identification information; also for example, the system mainly comprises account identification information and a unique identifier, wherein the account identification information is account identification information of the user account, and the unique identifier has uniqueness under the user account.

And 503, the server sets the first unique identification information under the user account, wherein the user account can be determined according to the first unique identification information, and a plurality of different unique identification information are allowed to be set under the user account.

The server sets the first unique identification information under the user account, wherein the user account can be determined according to the first unique identification information, and a plurality of different unique identification information are allowed to be set under the user account.

The server sets the first unique identification information under the user account, and enables the user account to be determined according to the first unique identification information, and specifically, various embodiments can be included, for example, the first unique identification information is used as account identification information under the user account; for another example, the first unique identification information is composed of account identification information and a unique identifier of the user account, and the unique identifier is set under the user account; also for example, the first unique identification information is associated with account identification information of the user, and so on.

And step 504, the server establishes a corresponding relation between the first unique identification information and the first local payment asset.

The server establishes a corresponding relation between the first unique identification information and the first local payment asset, so that the first local payment asset can be acquired through the corresponding relation according to the first unique identification information.

It is understood that, as described in step 503 above, a plurality of different unique identification information are allowed to be set under the user account, and therefore, if the user has a second payment terminal, a third payment terminal, a fourth payment terminal, and the like, then referring to steps 501 to 504 above, second unique identification information may be set under the user account and a corresponding relationship between the second unique identification information and a second local payment asset may be established; setting third unique identification information under the user account, and establishing a corresponding relation between the third unique identification information and a third local payment asset; setting fourth unique identification information under the user account, and establishing a corresponding relation between the fourth unique identification information and a fourth local payment asset; and so on, and will not be described in detail.

For the specific implementation in step 501 to step 504, reference may also be made to the relevant description in step 201 of the foregoing embodiment, which is not described herein again.

And 505, the server side issues the first unique identification information and the first local payment asset to the first payment side.

And the server side issues the first unique identification information and the first local payment asset to the first payment side.

Correspondingly, the first payment terminal receives the first unique identification information and the first local payment asset sent by the server terminal.

Step 506, the first payment terminal locally saves the first unique identification information and the first local payment asset.

The first payment end locally saves the first unique identification information and the first local payment asset.

Various specific embodiments may be included in the above step 505 and step 506, and specifically, the specific embodiments may include:

for example, the server sends the first unique identification information and the first local payment asset to the first payment terminal, and the first payment terminal receives and locally stores the first unique identification information and the first local payment asset sent by the server.

For another example, taking a digital asset in a form of a balance as an example, if the server is the first unique identification information and the first local payment asset determined according to the unique identification information and the local payment asset pre-stored by the first payment terminal, the server returns confirmation information to the first payment terminal, where the confirmation information indicates that the server has determined the unique identification information and the local payment asset according to the unique identification information and the local payment amount pre-stored by the first payment terminal, and after receiving the confirmation information, the first payment terminal takes the pre-stored unique identification information as the first unique identification information locally stored and takes the pre-stored local payment amount as the first local payment asset locally stored.

For another example, taking a digital asset in a form of a balance as an example, the server sends the first unique identification information to the first payment terminal, and the first payment terminal receives and locally stores the first unique identification information; and the server returns confirmation information to the first payment terminal, wherein the confirmation information represents that the server determines the local payment asset according to the local payment amount pre-stored by the first payment terminal, and after the first payment terminal receives the confirmation information, the first payment terminal takes the pre-stored local payment amount as the locally-stored first local payment asset.

For another example, the server sends the first local payment asset to the first payment portal, which receives and locally saves the first local payment asset; and the server returns confirmation information to the first payment terminal, wherein the confirmation information represents that the server determines unique identification information by using the unique identification information pre-stored by the first payment terminal, and after the first payment terminal receives the confirmation information, the first payment terminal takes the pre-stored unique identification information as the first unique identification information locally stored.

For the specific implementation in step 505 and step 506, reference may also be made to the relevant descriptions in step 202 and step 301 of the above embodiment, which are not described herein again.

And 507, when the first payment terminal carries out local payment, deducting the digital assets of the local payment at this time from the first local payment assets stored locally, and generating a payment certificate, wherein the payment certificate comprises the first unique identification information and the paid digital assets.

When the first payment terminal carries out local payment, deducting the digital assets of the local payment from the first local payment assets stored locally, and generating payment credentials, wherein the payment credentials comprise the first unique identification information and the paid digital assets.

The deducting the digital asset paid locally at this time from the first locally paid asset stored locally may specifically include:

for example, taking digital assets in the form of balance as an example, the first payment terminal updates the local payment asset stored locally to the balance of the local payment asset before updating minus the paid digital asset.

For another example, in the case of a digital asset in the form of a character string, the first payment terminal changes the paid digital asset to unavailable from the local payment assets stored locally.

For the specific implementation in step 507, reference may also be made to the related description in step 302 of the above embodiment, which is not described herein again.

And step 508, the first payment terminal transmits the payment certificate to the first receiving terminal through local communication.

And the first payment end transmits the payment certificate to a first receiving end through local communication.

Correspondingly, the first receiving end receives the payment certificate transmitted by the first payment end through local communication.

For the specific implementation in step 508, reference may also be made to the related descriptions in step 303 of the above embodiment and step 401 of the embodiment, which are not described herein again.

Step 509, optionally, the first receiving end verifies the payment credential, and after verifying that the payment credential is legitimate, it is determined that the first payment end is successful in payment.

Optionally, the first receiving end verifies the payment credential, and after verifying that the payment credential is legal, it is determined that the first payment end succeeds in payment.

For the specific implementation in step 509, reference may also be made to the relevant description in step 402 of the foregoing embodiment, which is not described herein again.

And 510, the first receiving end sends the payment certificate to the server end.

The first receiving end sends the payment certificate to the server, for example, the first receiving end establishes network connection with the server, and the first receiving end sends the payment certificate to the server through a network; for another example, the first receiving end synchronizes the payment credential to an intermediary device, so that the intermediary device sends the payment credential to the service end through a network.

Correspondingly, the server receives the payment certificate sent by the first receiving end.

For the specific implementation in step 510, reference may also be made to the relevant description in step 403 in the foregoing embodiment, which is not described herein again.

Step 511, when the server receives the payment certificate sent by the first receiving terminal, the server verifies the payment certificate, if the payment certificate is verified to be legal, the server determines the first local payment asset according to the first unique identification information and the corresponding relation included in the payment certificate, and transfers the paid digital asset from the first local payment asset to an account where the first receiving terminal is located.

And at the server, when the server receives the payment certificate sent by the first receiving terminal, the server verifies the payment certificate, if the payment certificate is verified to be legal, the server determines the first local payment asset according to the first unique identification information included in the payment certificate, and transfers the paid digital asset from the first local payment asset to an account where the first receiving terminal is located.

Since the correspondence relationship between the first unique identification information and the first local payment asset is established in step 504, the server may determine the corresponding local payment asset (i.e., determine the first local payment asset) according to the first unique identification information and the correspondence relationship included in the payment credential.

Optionally, the implementation of the service verifying the payment credential may further include: if the corresponding user account is not determined according to the first unique identification information included in the payment voucher, determining that the payment voucher is illegal; or/and determining that the payment voucher is illegal if the corresponding local payment asset is not acquired according to the first unique identification information included in the payment voucher.

The allocating the paid digital assets from the first local payment assets to the account of the first receiving end may specifically include:

for example, taking digital assets in the form of balance as an example, the server subtracts the paid digital assets from the first local payment assets, and adds the paid digital assets to the balance of the account where the first receiving end is located.

For another example, taking digital assets in a form of balance as an example, the server subtracts the paid digital assets from the first local payment asset, and transfers the paid digital assets to an associated account bound to an account where the first receiving end is located.

For another example, taking digital assets in a character string form as an example, the paid digital assets in the first local payment asset are changed into digital assets under the account where the first receiving end is located.

The transferring the paid digital assets from the first local payment assets to the account of the first receiving end may further comprise: determining the account of the first receiving terminal according to account identification information of the account of the first receiving terminal included in the payment voucher or according to account identification information of the payment voucher sending terminal; or/and if the account where the first receiving end is located belongs to accounts on other service ends, the service end transfers the paid digital assets from the first local payment assets to the other service ends, so that the other service ends transfer the paid digital assets into the account where the first receiving end is located.

The specific implementation manner in step 511 may also refer to the related description in step 203 of the above embodiment, and is not described herein again.

Further, in the process of implementing the above steps 502 to 504, the first unique identification information may be associated with payment end information (such as name, type, or the like of the first payment end) of the first payment end, so that the service end may know the usage of the local payment asset on the first payment end according to the usage of the local payment asset (i.e., the first local payment asset) corresponding to the first unique identification information.

And 512, when the server releases the first local payment asset corresponding to the first unique identification information, determining the first local payment asset to the user account according to the first unique identification information, and returning the first local payment asset to the existing digital asset of the user account.

When the server releases the first local payment asset corresponding to the first unique identification information, determining the user account according to the first unique identification information, and returning the first local payment asset to the existing digital asset of the user account.

Since the first unique identification information is set under the user account in the above step 502 and step 503, the determining the user account according to the first unique identification information corresponding to the setting manner may specifically include: if the first unique identification information is used as account identification information under the user account, determining the user account according to the first unique identification information; or, if the first unique identification information mainly consists of account identification information and a unique identifier, determining the user account according to the account identification information included in the first unique identification information; or, if the first unique identification information is associated with account identification information, acquiring the associated account identification information according to the first unique identification information, where the account identification information may be used to determine the user account.

The returning of the first local payment asset to the existing digital asset of the user account may specifically include:

for example, taking digital assets in the form of balance as an example, the first local payment asset is added to the balance of the user account, or the first local payment asset is transferred to the associated account bound to the user account.

For another example, taking digital assets in the form of character strings as an example, the first local payment asset is set as an existing digital asset under the user account.

For another example, taking digital assets in a character string form as an example, if the user account is also used for digital assets in a balance form, an amount equal to the first local payment asset amount is added to the balance of the user account, or if the user account is also bound with an associated account for digital assets in a balance form, digital assets in a balance form and an amount equal to the first local payment asset amount are transferred to the bound associated account.

It can be understood that, according to actual needs, if all the balance or remaining value of the first local payment asset is released, the balance or remaining value is returned to the existing digital asset of the user account; if the released part is the balance or the surplus value of the first local payment asset at the moment, correspondingly, the part which is also the balance or the surplus value in the existing digital asset of the user account is returned.

For the case that a user may have multiple payment terminals, there is a possible solution to set up multiple user accounts for the user, each account is bound with a payment terminal, and it can also be understood that a corresponding user account is set up for each payment terminal, however, since this solution is to set up multiple user accounts for the same user, it is necessary to set up digital assets for transfer of digital assets for the multiple user accounts, respectively, which increases the complexity of the user in account management and digital asset management, through the embodiments of the present invention, not only can multiple payment terminals of the same user obtain respective local payment assets, respectively, but also share the same user account, including sharing existing digital assets under the same user account for transfer of local payment assets, and when releasing the local payment assets, the local payment asset is returned to an existing digital asset under the same user account.

The above implementation process is exemplified by combining the first embodiment, the second embodiment and the third embodiment of the method for supporting local payment by multiple payment terminals of the same user, and implementing a complete process by the server, the first payment terminal and the first receiving terminal shown in fig. 1, and the generated technical effects may refer to the technical effects described in the first embodiment, the second embodiment and the third embodiment, which are not described herein again.

It should be noted that, in this document, the terms "comprises," "comprising," "includes," "passing," "sending," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system.

The terms "first," "second," "third," and the like (if any) are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. It will be appreciated that the data so used may be interchanged under appropriate circumstances such that the embodiments described herein may be practiced otherwise than as specifically illustrated or described herein.

The numbers of the above embodiments of the present invention are merely for description and do not represent the merits of the embodiments.

The method, payment end, receiving end and service end of the invention can be implemented in many ways. For example, the method, payment terminal, receiving terminal and service terminal of the present invention may be implemented by software, hardware, firmware or any combination of software, hardware, firmware. The above-described order for the steps of the method is for illustrative purposes only, and the steps of the method of the present invention are not limited to the order specifically described above unless specifically indicated otherwise. Furthermore, in some embodiments, the present invention may also be embodied as a program recorded in a recording medium, the program including machine-readable instructions for implementing a method according to the present invention. Thus, the present invention also covers a recording medium storing a program for executing the method according to the present invention.

The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims

1. The method for supporting local payment by a plurality of payment terminals of the same user is applied to a server terminal, and comprises the following steps:

2. The method of claim 1, further comprising:

3. The method for supporting local payment by a plurality of payment terminals of the same user is applied to the payment terminals, and comprises the following steps:

4. The method for supporting local payment by a plurality of payment terminals of the same user is applied to a receiving terminal, and comprises the following steps:

5. A server device, characterized in that the server device comprises a processor and a memory, the processor is used for executing a program stored in the memory, and the program executes the method according to any one of claims 1 to 2.

6. A payment end device comprising a processor, a memory, the processor for executing a program stored in the memory, the program when executed performing a method according to claim 3.

7. A sink device, characterized in that the sink device comprises a processor and a memory, the processor is configured to execute a program stored in the memory, and the program executes the method according to claim 4.

8. A chip, comprising: a processor for calling and running a computer program from a memory, causing a device on which the chip is installed to perform the method of claim 3, or causing a device on which the chip is installed to perform the method of claim 4.

9. A system, characterized in that the system comprises a server device, a payment device and a receiving device, wherein the server device comprises the server device as claimed in claim 5, and the payment device comprises the payment device as claimed in claim 6; the sink device comprises the sink device according to claim 7.

10. A storage medium, characterized in that the storage medium has stored therein a program for implementing a method comprising any one of claims 1 to 2, or a program for implementing a method comprising claim 3, or a program for implementing a method comprising claim 4.