WO2016173035A1 - 基于同一资金管理服务器的支付系统及方法、装置、服务器 - Google Patents

基于同一资金管理服务器的支付系统及方法、装置、服务器 Download PDF

Info

Publication number
WO2016173035A1
WO2016173035A1 PCT/CN2015/080048 CN2015080048W WO2016173035A1 WO 2016173035 A1 WO2016173035 A1 WO 2016173035A1 CN 2015080048 W CN2015080048 W CN 2015080048W WO 2016173035 A1 WO2016173035 A1 WO 2016173035A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
management server
information
fund management
client
Prior art date
Application number
PCT/CN2015/080048
Other languages
English (en)
French (fr)
Inventor
张毅
Original Assignee
深圳市银信网银科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳市银信网银科技有限公司 filed Critical 深圳市银信网银科技有限公司
Priority to CA2987800A priority Critical patent/CA2987800A1/en
Publication of WO2016173035A1 publication Critical patent/WO2016173035A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols

Definitions

  • the present invention relates to the field of electronic commerce, and in particular, to a payment system, method, device, and server based on the same fund management server.
  • E-commerce has become more and more widely used in various commercial trade activities.
  • the so-called e-commerce refers to online shopping for consumers based on browser and server applications in the open Internet environment of commercial trade activities.
  • the technical problem to be solved by the present invention is to provide a payment system, method, device and server based on the same fund management server, so as to reduce the risk of user funds and protect the interests of both buyers and sellers.
  • a payment system based on the same fund management server comprising at least one client, at least one merchant, an information center server, and a fund management server, wherein the fund management server is respectively connected to the client, the merchant, and the information center server, among them:
  • the client configured to send, to the fund management server, payment request information including at least a payment amount
  • the merchant terminal is configured to receive an electronic commitment payment certificate sent by the fund management server;
  • a fund management server configured to receive payment request information sent by the client; compare a client fund balance and a payment amount, and determine whether an electronic commitment payment certificate can be generated for payment; if so, the fund management server freezes the client account And the funds corresponding to the payment amount, generating an electronic commitment payment certificate that is promised by the fund management server to cancel the payment according to the agreed condition, and sending the electronic commitment payment voucher information to the merchant terminal for crediting the client Committed to paying and synchronizing the electronic commitment payment voucher information to the information center server.
  • An information center server is configured to store and supervise the electronic commitment payment voucher information.
  • a network payment method based on the same money management server comprising the steps of:
  • the fund management server receives the payment request information sent by the client, where the payment request information includes at least the payment amount;
  • the fund management server freezes the funds corresponding to the payment amount in the client account; generates an electronic commitment payment voucher that is promised by the fund management server to release the funds according to the agreed conditions, and the electronic commitment
  • the payment voucher information is sent to the merchant for credit commitment payment for the client, and the electronic commitment payment voucher information is synchronized to the information center server.
  • the client account credit overdraft limit and the payment amount are compared to determine whether the electronic commitment payment certificate can be generated for payment; further, if the client account credit overdraft limit is less than the payment amount, the customer is compared.
  • the end account credit loan amount and the payment amount determine whether an electronic promise payment voucher can be generated for payment.
  • a payment device based on the same fund management server, the device comprising a receiving module, a determining module and a processing module, wherein:
  • a receiving module configured to receive payment request information sent by the client, where the payment request information includes a payment amount
  • a determining module configured to determine whether to allow payment according to the client fund balance and the payment amount
  • a processing module configured to: when the payment is allowed, freeze the funds corresponding to the payment amount or the credit overdraft limit or the credit loan amount in the client account; generate an electronic commitment payment voucher, and send the electronic commitment payment voucher information to Merchant side and sync to the information center server.
  • a server based on the same money management server the server comprising the payment device of any of the preceding claims.
  • the payment system, method, device and server based on the same fund management server provided by the invention supervise the information of the buyer and the seller through the fund management server and the information center server, and integrate the supervision function into the bank or other institution with credit payment capability
  • the risk of funds can be reduced and the interests of both buyers and sellers can be protected; this solution makes full use of the credit center of the fund management server.
  • the risk control center function of the information center server promotes network transactions and secures transaction funds with a more optimized credit mechanism, provides a credit medium for both parties to the transaction, and reduces the risk of funds through the supervision of funds to protect the interests of both parties.
  • it also facilitates customers by adding loan functions, and enriches the business of banks or other institutions with credit payment capabilities.
  • FIG. 1 is a schematic diagram of a payment system based on the same fund management server according to Embodiment 1 of the present invention
  • FIG. 2 is a flowchart of a payment method based on the same fund management server according to Embodiment 2 of the present invention
  • FIG. 3 is a flowchart of a payment method based on the same fund management server according to Embodiment 3 of the present invention.
  • FIG. 4 is a flowchart of a payment method based on the same fund management server according to Embodiment 4 of the present invention.
  • FIG. 5 is a flowchart of a payment method based on the same fund management server according to Embodiment 5 of the present invention.
  • FIG. 6 is a flowchart of a payment method based on the same fund management server according to Embodiment 6 of the present invention.
  • FIG. 7 is a block diagram showing the structure of a payment device based on the same fund management server according to Embodiment 7 of the present invention.
  • FIG. 8 is a block diagram showing the structure of a payment system based on the same fund management server according to Embodiment 8 of the present invention.
  • a payment system based on the same fund management server is provided in an embodiment of the present invention.
  • the system includes at least one client 10, at least one merchant terminal 20, an information center server 40, and a fund management server 30.
  • the server 30 is connected to the client 10, the merchant 20, and the information center server 40, respectively:
  • the client 10 is connected to the fund management server 30 for transmitting payment request information to the fund management server 30, wherein the payment request information includes a payment amount.
  • the client 10 is applicable to a payer (buyer), including a smart device such as a mobile phone, a personal computer, a PAD, etc., and the account information of the client 10 is filled in when the user registers, and is stored in the fund management server and/or the information center server.
  • the account information of the client 10 includes information such as a user ID, an account bank, an account name, a bank account number, a credit limit, and the like, and may also include a customer's receipt/service address information.
  • the payment request information is information such as filling in/confirming the receipt/service address after the user selects to purchase a specific product/service, and the client 10 generates data according to the price of the product/service and the merchant to which the product/service belongs according to a preset rule.
  • the packet is sent to the fund management server 30.
  • the payment request information includes at least a payment amount, and may also include merchant information and commodity information.
  • the merchant information may directly be the merchant payment account, or may uniquely identify the merchant information (such as the merchant ID), and the fund management server 30 searches the database for the bank account information corresponding to the merchant according to the unique identifier of the merchant.
  • the account information of the merchant terminal 20 should be confidential with respect to the client 10, so the merchant information is preferably a merchant ID, and the fund management server 30 uses the relationship between the merchant ID and the payment account to query the merchant's payment account. . That is to say, the client 10 only needs to inform the merchant management server 30 which merchant to pay for which merchandise, and the fund management server 30 can call the merchant's account to realize the payment.
  • the merchant terminal 20 is connected to the fund management server 30 for receiving the electronic commitment payment certificate sent by the fund management server 30.
  • the merchant terminal 20 is applicable to a payee (seller), and the merchant terminal includes but is not limited to a server, a POS machine, and the like.
  • Merchants include, but are not limited to, manufacturers, agents, logistics companies, etc.
  • the merchant information is also registered when the user opens the account and is stored in the database of the fund management server and/or the information center server.
  • the merchant information includes but is not limited to the merchant ID, the merchant name, the merchant account bank, the merchant account name, the merchant bank account, and the like. .
  • the fund management server 30 is configured to receive the payment request information sent by the client 10; determine whether the payment is allowed according to the credit overdraft limit, the fund balance, the credit loan amount, and the payment amount of the client 10; if the payment is allowed, the client account is frozen.
  • the credit amount or the fund corresponding to the payment amount is generated, and the electronic commitment payment certificate promised by the fund management server to cancel the payment according to the agreed condition is generated, and the electronic commitment payment voucher information is sent to the merchant terminal 20 and synchronized to the information center server 40.
  • the fund management server 30 parses according to a preset rule to obtain related payment information, and the related payment information includes, but is not limited to, necessary information such as merchant information, product information, and payment amount, that is, Which merchant's product is paid for which product.
  • the information center server 40 is connected to the fund management server 30 for storing electronic commitment payment voucher information of the client 10 and the merchant terminal 20.
  • both the client 10 and the merchant 20 can obtain the electronic commitment payment credential information from the information center server 40 through the Internet for subsequent processing, such as using the data to verify whether the two-channel verification information is correct or not.
  • the fund management server 30 can further determine whether the payment operation is based on the status of the electronic commitment payment voucher information, that is, the request payment is only to freeze the funds, and the withdrawal operation is performed after the receipt is confirmed.
  • the same fund management server 30 can also be connected to the plurality of clients 10 and the plurality of merchant terminals 20 via the Internet at the same time. That is, the server where the merchant 20 account is located and the server where the client 10 is located are both the same fund management server 30.
  • the same fund management server 30 can be a single server in a physical sense, or can be multiple servers in a physical sense, such as multiple physical servers working in parallel, automatically allocating server resources according to different traffic volumes, and jointly implementing fund management. .
  • the money management server includes, but is not limited to, servers in organizations such as banks and enterprises. In practical applications, it can be understood as a cluster fund management server of the same bank, but it is not limited to banks.
  • the fund management server and the information center server supervise the information of the buyer and the seller, and integrate the supervision function into the bank or other institutions with credit payment capabilities.
  • a payment method based on the same fund management server according to an embodiment of the present invention is applied to a fund management server, and the method includes the following steps:
  • the fund management server 30 receives the payment request information sent by the client, and the payment request information includes at least the payment amount.
  • the payment request information received by the fund management server includes: merchant information, commodity information, and payment amount, and may further include client information (such as a customer ID).
  • the merchant information may directly be the merchant payment account, or may uniquely identify the merchant information (such as the merchant ID), and the fund management server searches the database for the bank account information corresponding to the merchant according to the unique identifier of the merchant.
  • the account information of the merchant side should be confidential with respect to the client, so the merchant information is preferably a merchant ID, and the fund management server uses the relationship between the merchant ID and the payment account to query the merchant's payment account. That is to say, the client only needs to inform the merchant management server which merchant to pay for which commodity, and the fund management server can call the merchant's account to implement the corresponding payment operation.
  • the step further includes: the fund management server querying the balance of the account fund of the client from the database; determining whether the balance of the fund is greater than or equal to the payment amount; if yes, allowing the payment; otherwise, terminating the payment.
  • the bank account of the client may be that the client informs the fund management server in the payment request information, or the fund management server may query the database according to the client ID, thereby obtaining the balance of the corresponding account fund. Only when the account balance of the client is greater than or equal to the payment amount, indicates that the customer has the ability to pay, and the payment behavior is allowed at this time. Priority is given to the payment of the balance of the account funds, which can save the payment cycle and protect the interests of the merchants.
  • the fund management server freezes the funds corresponding to the payment amount in the client account
  • the fund management server will transfer the thawed funds to the merchant account after receiving the payment information.
  • the fund management server generates an electronic commitment payment voucher
  • the fund management server freezes the corresponding funds or credit lines, and generates electronic commitment payment vouchers according to the payment information.
  • the electronic commitment payment vouchers information includes but is not limited to commodity information, payment amount (frozen funds), delivery address and expiration date, and the form is not limited. Text, pictures, graphic codes, etc.
  • the electronic voucher serves as a voucher for receiving funds from the merchant, and the merchant provides corresponding goods/services according to the electronic commitment payment voucher.
  • S105 Send an electronic commitment payment certificate to the merchant to perform credit commitment payment for the client and synchronize to the information center server.
  • the generated electronic voucher information is sent to the information center server, so that the information center server performs subsequent tracking.
  • the fund management server receives the payment request information of the client through the fund management server, determines whether the payment is allowed according to the balance of the account fund of the buyer, and freezes the payment amount of the client account, and generates
  • the electronic commitment payment vouchers are synchronized to the information center server for real-time monitoring, which can reduce the risk of funds and protect the interests of both buyers and sellers.
  • the fund management server receives the settlement information.
  • the fund management server receives and judges whether the settlement information conforms to the agreed settlement fund condition.
  • the fund management server determines to synchronize the settlement information to the information center server.
  • the fund management server transfers the funds to the account of the merchant.
  • a payment method based on the same fund management server according to an embodiment of the present invention is applied to a fund management server, and the method includes the following steps:
  • the fund management server 30 receives the payment request information sent by the client, and the payment request information includes a payment amount.
  • the payment request information received by the fund management server includes: merchant information, commodity information, and payment amount, and may further include client information (such as a customer ID).
  • the merchant information may directly be the merchant payment account, or may uniquely identify the merchant information (such as the merchant ID), and the fund management server searches the database for the bank account information corresponding to the merchant according to the unique identifier of the merchant.
  • the account information of the merchant side should be confidential with respect to the client, so the merchant information is preferably a merchant ID, and the fund management server uses the relationship between the merchant ID and the payment account to query the merchant's payment account. That is to say, the client only needs to inform the merchant management server which merchant to pay for which commodity, and the fund management server can call the merchant's account to implement the corresponding payment operation.
  • step S203 querying the balance of the funds of the client account is sufficient, if not, step S204 is performed, otherwise step S207 is performed;
  • step S204 Query whether the credit overdraft limit of the client account is sufficient, and if not, terminate the payment, otherwise step S207 is performed;
  • the fund management server will transfer the thawed funds to the merchant account after receiving the payment information.
  • the merchant sends and receives the settlement information to the fund management server.
  • the merchant sends and receives the settlement information to the fund management server, which is merely an example.
  • the client, the logistics server, or other entity capable of obtaining the delivery status may also manage the funds.
  • the server sends the settlement information.
  • the fund management server synchronizes the settlement information to the information center server.
  • the fund management server synchronizes the updated electronic commitment payment voucher information to the information center server, and can immediately know the circulation status of the goods from the updated electronic commitment payment voucher information, and when the goods/services are delivered, the frozen funds can be drawn. Payment to the merchant's account.
  • the payment method of the fund balance or the credit overdraft balance receives the payment request information of the client through the fund management server, determines whether the payment is allowed according to the balance of the buyer's fund and the credit overdraft balance, and simultaneously freezes the payment amount of the client account. And generate electronic commitment payment vouchers to the information center server for real-time monitoring, which can reduce the risk of funds and protect the interests of both buyers and sellers.
  • a payment method based on the same fund management server is applied to a fund management server according to an embodiment of the present invention.
  • the method includes the following steps:
  • the fund management server 30 receives the payment request information sent by the client, and the payment request information includes a payment amount.
  • the payment request information received by the fund management server includes: merchant information, commodity information, and payment amount, and may further include client information (such as a customer ID).
  • the merchant information may directly be the merchant payment account, or may uniquely identify the merchant information (such as the merchant ID), and the fund management server searches the database for the bank account information corresponding to the merchant according to the unique identifier of the merchant.
  • the account information of the merchant side should be confidential with respect to the client, so the merchant information is preferably a merchant ID, and the fund management server uses the relationship between the merchant ID and the payment account to query the merchant's payment account. That is to say, the client only needs to inform the merchant management server which merchant to pay for which commodity, and the fund management server can call the merchant's account to implement the corresponding payment operation.
  • step S203 query whether the balance of the client account is sufficient, if not, step S205 is performed, otherwise step S207 is performed;
  • step S205 Query whether the credit loan amount of the client account is sufficient, and if not, terminate the payment, otherwise step S207 is performed;
  • the fund management server will transfer the unfrozen funds or the funds equivalent to the credit loan amount to the merchant account after receiving the payment information.
  • the merchant sends and receives the settlement information to the fund management server.
  • the merchant sends and receives the settlement information to the fund management server, which is merely an example.
  • the client, the logistics server, or other entity capable of obtaining the delivery status may also manage the funds.
  • the server sends the settlement information.
  • the fund management server synchronizes the settlement information to the information center server.
  • the fund management server synchronizes the updated electronic commitment payment voucher information to the information center server, and can immediately know the circulation status of the goods from the updated electronic commitment payment voucher information, and when the goods/services are delivered, the frozen funds can be drawn. Payment to the merchant's account.
  • the payment method of the fund balance or the credit loan balance of the embodiment of the present invention receives the payment request information of the client through the fund management server, determines whether the payment is allowed according to the balance of the buyer's fund and the credit of the credit, and simultaneously freezes the payment amount of the client account. And generate electronic commitment payment vouchers to the information center server for real-time monitoring, which can reduce the risk of funds and protect the interests of both buyers and sellers.
  • a payment method based on the same fund management server provided in this embodiment is applied to a fund management server, and the method includes the following steps:
  • the client sends payment request information to the fund management server, where the payment request information includes a payment amount, and the fund management server receives the payment request information sent by the client.
  • the payment request information is composed of a plurality of data packets, and at least includes merchant information, commodity information, and payment amount. It can also include client information such as customer IDs.
  • the merchant information may directly be the merchant payment account, or may uniquely identify the merchant information (such as the merchant ID), and the fund management server searches the database for the bank account information corresponding to the merchant according to the unique identifier of the merchant.
  • the account information of the merchant side should be confidential with respect to the client, so the merchant information is preferably a merchant ID, and the fund management server uses the relationship between the merchant ID and the payment account to query the merchant's payment account. That is to say, the client only needs to inform the merchant management server which merchant to pay for which commodity, and the fund management server can call the merchant's account to implement the corresponding payment operation.
  • the manner in which the client sends the payment request information to the fund management server can be performed in an existing manner, such as by using a digital signature or a digital envelope.
  • a digital signature is data obtained by a user encrypting a hash digest of the original data with his or her private key.
  • the information receiver obtains the hash digest after decrypting the digital signature attached to the original information using the public key of the information sender, and can confirm whether the original information is obtained by comparing with the hash sum generated by the original data received by the user. Was tampered with. This ensures the non-repudiation of data transmission.
  • Digital envelopes use cryptographic techniques to ensure that only the intended recipient can read the content of the message. A single key cryptosystem and a public key cryptosystem are used in the digital envelope.
  • the sender of the information first encrypts the information by using a randomly generated symmetric cipher, and then encrypts the symmetric cipher with the public key of the recipient.
  • the symmetric cipher encrypted by the public key is called a digital envelope.
  • the information receiver When transmitting information, when the information receiver wants to decrypt the information, it must first decrypt the digital envelope with its own private key to obtain a symmetric password, in order to use the symmetric password to decrypt the obtained information. This ensures the authenticity and integrity of the data transmission.
  • step S203 querying the balance of the funds of the client account is sufficient, if not, step S204 is performed, otherwise step S207 is performed;
  • step S204 query the credit account overdraft quota of the client account is sufficient, if not, step S205 is performed, otherwise step S207 is performed;
  • step S205 Query whether the credit loan amount of the client account is sufficient, and if not, terminate the payment, otherwise step S207 is performed;
  • the merchant sends and receives the settlement information to the fund management server.
  • the merchant sends and receives the settlement information to the fund management server, which is merely an example.
  • the client, the logistics server, or other entity capable of obtaining the delivery status may also manage the funds.
  • the server sends the settlement information.
  • the fund management server synchronizes the settlement information to the information center server.
  • the money management server synchronizes the updated electronic commitment payment voucher information to the information center server, and when the goods/services are delivered, the frozen funds can be transferred to the merchant's account.
  • the buyer is not only convenient, but also greatly enriches the loan business of the bank or other third party institutions;
  • the server synchronously tracks the electronic commitment payment vouchers of the buyer and the seller, and effectively combines the trajectory of the goods and the trajectory of the funds, so that the interests of both buyers and sellers can be effectively protected.
  • the payment method based on the same fund management server provided in this embodiment is applied to a fund management server, and the method includes the following steps:
  • the client sends payment request information to the fund management server, where the payment request information includes a payment amount, and the fund management server receives the payment request information sent by the client.
  • the payment request information is composed of a plurality of data packets, and at least includes merchant information, commodity information, and payment amount. It can also include client information such as customer IDs.
  • the merchant information may directly be the merchant payment account, or may uniquely identify the merchant information (such as the merchant ID), and the fund management server searches the database for the bank account information corresponding to the merchant according to the unique identifier of the merchant.
  • the account information of the merchant side should be confidential with respect to the client, so the merchant information is preferably a merchant ID, and the fund management server uses the relationship between the merchant ID and the payment account to query the merchant's payment account. That is to say, the client only needs to inform the merchant management server which merchant to pay for which commodity, and the fund management server can call the merchant's account to implement the corresponding payment operation.
  • the manner in which the client sends the payment request information to the fund management server can be performed in an existing manner, such as by using a digital signature or a digital envelope.
  • a digital signature is data obtained by a user encrypting a hash digest of the original data with his or her private key.
  • the information receiver obtains the hash digest after decrypting the digital signature attached to the original information using the public key of the information sender, and can confirm whether the original information is obtained by comparing with the hash sum generated by the original data received by the user. Was tampered with. This ensures the non-repudiation of data transmission.
  • Digital envelopes use cryptographic techniques to ensure that only the intended recipient can read the content of the message. A single key cryptosystem and a public key cryptosystem are used in the digital envelope.
  • the sender of the information first encrypts the information by using a randomly generated symmetric cipher, and then encrypts the symmetric cipher with the public key of the recipient.
  • the symmetric cipher encrypted by the public key is called a digital envelope.
  • the information receiver When transmitting information, when the information receiver wants to decrypt the information, it must first decrypt the digital envelope with its own private key to obtain a symmetric password, in order to use the symmetric password to decrypt the obtained information. This ensures the authenticity and integrity of the data transmission.
  • step S203 querying the balance of the funds of the client account is sufficient, if not, step S204 is performed, otherwise step S207 is performed;
  • step S204 querying the credit account credit of the client account is sufficient, if not, step S204 is performed, otherwise step S207 is performed;
  • step S205 Query whether the credit overdraft limit of the client account is sufficient, and if not, terminate the payment, otherwise step S207 is performed;
  • the merchant sends and receives the settlement information to the fund management server.
  • the merchant sends and receives the settlement information to the fund management server, which is merely an example.
  • the client, the logistics server, or other entity capable of obtaining the delivery status may also manage the funds.
  • the server sends the settlement information.
  • the fund management server synchronizes the settlement information to the information center server.
  • the money management server synchronizes the updated electronic commitment payment voucher information to the information center server, and when the goods/services are delivered, the frozen funds can be transferred to the merchant's account.
  • the buyer is not only convenient, but also greatly enriches the credit overdraft business of the bank or other third party institutions; in addition, by adding information
  • the central server synchronously tracks the electronic commitment payment vouchers of the buyer and the seller, and effectively combines the trajectory of the goods and the trajectory of the funds, so that the interests of both buyers and sellers can be effectively protected.
  • a payment device provided by an embodiment of the present invention includes a receiving module 301, a determining module 302, and a processing module 303, where:
  • the receiving module 301 is configured to receive payment request information sent by the client, where the payment request information includes a payment amount.
  • the payment request information received by the receiving module 301 includes: merchant information, product information, and payment amount, and may further include client information (such as a customer ID).
  • the merchant information may directly be a merchant collection account, or may uniquely identify the merchant's information (such as a merchant ID).
  • the account information of the merchant side should be kept secret relative to the client, so the merchant information is preferably the merchant ID, that is, the client only needs to inform the fund management server which merchant to pay for which commodity, which is adjusted by the device.
  • the account of the merchant is implemented to perform the corresponding payment operation.
  • the determining module 302 is configured to determine whether to allow payment according to the client fund balance, the credit overdraft balance or the credit loan balance and the payment amount.
  • the determining module 302 is specifically configured to: query the account fund balance of the client; determine whether the fund balance of the client account is greater than or equal to the payment amount, and if yes, allow payment; otherwise, further determine the client account. Whether the credit overdraft balance is greater than or equal to the payment amount, if yes, the payment is allowed; otherwise, it is further determined whether the account fund credit balance is greater than the payment amount, and if so, the payment is allowed, otherwise payment is not allowed. In this way, the account fund balance, the credit overdraft balance and the credit loan balance payment ability are determined in turn, and the payment of the account fund balance is preferentially used, which can save the payment cycle and protect the interests of the merchant.
  • the bank account of the client may be that the client informs the device in the payment request information, or the device may query the database according to the client information, and obtain the corresponding account fund balance, credit balance and loan balance. Only when the client's fund balance is greater than or equal to the payment amount, indicates that the customer has the ability to make payment behavior, and then the payment behavior is allowed.
  • the fund management server When using the fund management server to obtain a bank account or a credit card account based on customer information, a customer may have multiple accounts, and a hybrid payment method may also be employed.
  • the processing module 303 is configured to: when the payment is allowed, freeze the funds or the amount corresponding to the payment amount in the client account; generate an electronic commitment payment voucher, send the electronic commitment payment voucher information to the merchant, and synchronize to the information center server.
  • the processing module 303 further includes a freezing unit 3031, a credential generating unit 3032, and a synchronizing unit 3033, wherein:
  • the freezing unit 3031 is configured to freeze the funds or the amount corresponding to the payment amount in the client account when the payment is allowed;
  • a voucher generating unit 3032 configured to generate an electronic commitment payment voucher
  • the synchronization unit 3033 is configured to send the electronic commitment payment credential information to the merchant and synchronize to the information center server.
  • processing module 303 may further include a debiting unit configured to, after receiving the disbursement information, synchronize the dissolving information to the information center server, and transfer the frozen funds to the account of the merchant.
  • the present invention also provides a fund management server, which includes the payment device in the fourth embodiment, which will not be repeated here.
  • the payment device and the server of the embodiment of the present invention determine whether the payment is allowed according to the buyer's fund balance, the credit overdraft limit, and the credit loan amount by receiving the payment request information of the client, and simultaneously freeze the payment amount of the client account and generate an electronic commitment.
  • the payment voucher is synchronized to the information center server for real-time monitoring, which can reduce the risk of funds and protect the interests of both buyers and sellers.
  • by increasing the loan function it not only facilitates the buyer, but also greatly enriches the business of banks or other institutions with credit payment capabilities.
  • the system includes a client 10, a merchant terminal 20, a fund management server 30, and an information center server 50, wherein:
  • the information center server 50 is configured to store and supervise the electronic commitment payment voucher information.
  • the client 10, including the payment request module 101, is configured to send payment request information to the fund management server 30, wherein the payment request information includes: merchant information, commodity information, and payment amount.
  • the merchant terminal 20 includes a voucher receiving module 201 and a settlement information transmitting module 202, wherein the voucher receiving module 201 is configured to receive the electronic commitment payment voucher sent by the fund management server 30.
  • the fund management server 30 includes a receiving module 301, a determining module 302, and a processing module 303, wherein:
  • the receiving module 301 is configured to receive payment request information sent by the client.
  • the determining module 302 is configured to determine whether to allow payment according to the client fund balance and the payment amount;
  • the determining module 302 is configured to: determine whether the fund balance of the client account is greater than or equal to the payment amount, and if yes, allow the payment; otherwise, further determine whether the credit overdraft balance of the client account is greater than or equal to the payment. The amount, if yes, is allowed to pay.
  • the processing module 303 is configured to: when the payment is allowed, freeze the funds or the amount corresponding to the payment amount in the client account; generate an electronic commitment payment voucher, send the electronic commitment payment voucher information to the merchant, and synchronize to the information center server.
  • the receiving module 301 of the money management server 30 is further configured to receive the dissolving information; the processing module 303 further includes a debiting module configured to synchronize the dissolving information to the information center server after receiving the dissolving information And transfer the frozen funds to the account of the merchant.
  • the payment request information is sent by the buyer to the fund management server 30 through the operation of the client 10, the payment information is objectively confirmed by the client 10 and authorized to be paid by the bank.
  • the fund management server 30 freezes the corresponding funds or quotas, and generates an electronic commitment payment certificate according to the payment information, and the electronic commitment payment voucher information includes but is not limited to commodity information, payment amount (frozen funds), delivery address, and expiration date, in the form Not limited to text, pictures, graphic codes, and the like.
  • the electronic voucher serves as a voucher for receiving funds from the merchant terminal 20, and the merchant terminal 20 provides corresponding goods/services according to the electronic commitment payment voucher.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明公开了一种基于同一资金管理服务器的支付系统及方法、装置、服务器，属于电子商务领域。其中，该方法包括：资金管理服务器接收客户端发送的支付请求信息；比较客户端资金余额或授信透支额度或授信贷款额度和支付金额判断能否开出电子承诺支付凭证；若能，资金管理服务器冻结客户端账户内与支付金额对应的资金余额；生成资金管理服务器承诺按约定条件解付资金的电子承诺支付凭证，将该电子承诺支付凭证发送给商户端替所述客户端进行信用承诺支付，并同步到信息中心服务器。采用本发明技术方案，将交易双方予以监管能降低资金风险，保障交易双方的利益。

Description

基于同一资金管理服务器的支付系统及方法、装置、服务器
【技术领域】
本发明涉及电子商务领域，尤其涉及一种基于同一资金管理服务器的支付系统及方法、装置、服务器。
【背景技术】
电子商务已越来越广泛地应用于各种商业贸易活动中，所谓电子商务是指在商业贸易活动中，在因特网开放的网络环境下，基于浏览器及服务器应用方式，实现消费者的网上购物、商户之间的网上交易和在线电子支付以及各种商务活动、交易活动、金融活动和相关的综合服务活动的一种商业运营模式。
目前，很多银行或者企业都提供了网络支付的服务，允许客户操作计算机、手机等终端设备来实现网络支付，网络支付的方式为客户提供了很大的便利。而网络支付的过程中，多为使用借记卡内的现有资金或信用卡直接支付，或将现有资金或信用卡内的信用额度等额资金直接划拨到第三方机构作为担保进行交易，一旦商户未提供商品或服务时有或者发生客户争议时，资金安全难以得以保证。由此可见，现阶段需要新的支付系统、方法、装置和服务器，以降低用户资金风险，保障买卖双方的利益。
【发明内容】
有鉴于有鉴于此，本发明要解决的技术问题是提供一种基于同一资金管理服务器的支付系统及方法、装置、服务器，以降低用户资金风险，保障买卖双方的利益。
本发明解决上述技术问题所采用的技术方案如下：
一种基于同一资金管理服务器的支付系统，包括至少一个客户端、至少一个商户端、信息中心服务器和资金管理服务器，所述资金管理服务器分别与所述客户端、商户端和信息中心服务器连接，其中：
所述客户端，用于向所述资金管理服务器发送至少包括有支付金额的支付请求信息；
所述商户端，用于接收所述资金管理服务器发送的电子承诺支付凭证；
资金管理服务器，用于接收所述客户端发送的支付请求信息；比较客户端资金余额和支付金额并判断能否生成电子承诺支付凭证予以支付；若能，资金管理服务器冻结所述客户端账户内与所述支付金额对应的资金，生成由所述资金管理服务器承诺按约定条件解付资金的的电子承诺支付凭证，并将所述电子承诺支付凭证信息发送给商户端替所述客户端进行信用承诺支付，并将所述电子承诺支付凭证信息同步到所述信息中心服务器。
信息中心服务器，用于存储并监管所述电子承诺支付凭证信息。
根据本发明的另一个方面，提供的一种基于同一资金管理服务器的网络支付方法，该方法包括以下步骤：
资金管理服务器接收客户端发送的支付请求信息，其中，支付请求信息至少包括支付金额；
比较所述客户端资金余额和所述支付金额并判断能否生成电子承诺支付凭证予以支付；
若能，所述资金管理服务器冻结所述客户端账户内与所述支付金额对应的资金；生成由所述资金管理服务器承诺按约定条件解付资金的的电子承诺支付凭证，将所述电子承诺支付凭证信息发送给商户端替所述客户端进行信用承诺支付，并将所述电子承诺支付凭证信息同步到信息中心服务器。
如果客户端账户资金余额小于支付金额时，则比较客户端账户授信透支额度和支付金额判断能否生成电子承诺支付凭证予以支付；进一步，如果客户端账户授信透支额度小于支付金额时，则比较客户端账户授信贷款额度和支付金额判断能否生成电子承诺支付凭证予以支付。
如果客户端账户资金余额小于支付金额时，则比较客户端账户授信贷款额度和支付金额判断能否生成电子承诺支付凭证予以支付；进一步，如果客户端账户授信贷款额度小于支付金额时，则比较客户端账户授信透支额度和支付金额判断能否生成电子承诺支付凭证予以支付。
根据本发明的又一个方面，提供的一种基于同一资金管理服务器的支付装置，所述装置包括接收模块、判断模块和处理模块，其中：
接收模块，设置为接收客户端发送的支付请求信息，其中，所述支付请求信息包括支付金额；
判断模块，设置为根据所述客户端资金余额和所述支付金额判断是否允许支付；
处理模块，设置为当允许支付时，冻结所述客户端账户内的所述支付金额对应的资金或授信透支额度或授信贷款额度；生成电子承诺支付凭证，将所述电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。
一种基于同一资金管理服务器的服务器，所述服务器包括上述任意一项权利要求所述的支付装置。
本发明提供的基于同一资金管理服务器的支付系统及其方法、装置和服务器，通过资金管理服务器和信息中心服务器对买卖双方的信息进行监管，将监管功能合并到银行或其他具备信用支付能力的机构；同时通过冻结客户端账户的账户资金余额，并生成电子承诺支付凭证同步到信息中心服务器进行实时监控，能降低资金风险，保障买卖双方的利益；此方案充分利用了资金管理服务器的信用中枢和信息中心服务器的风控中心功能，以更加优化的信用机制促进网络交易和保障交易资金安全，为交易双方提供了信用媒介，还通过对资金的监管能降低资金风险，保障交易双方的利益。此外，还通过增加贷款功能方便了客户，也丰富了银行或其他具备信用支付能力的机构的业务。
【附图说明】
图1是本发明实施例一提供的一种基于同一资金管理服务器的支付系统的示意图；
图2是本发明实施例二提供的一种基于同一资金管理服务器的支付方法的流程图；
图3是本发明实施例三提供的一种基于同一资金管理服务器的支付方法的流程图；
图4是本发明实施例四提供的一种基于同一资金管理服务器的支付方法的流程图；
图5是本发明实施例五提供的一种基于同一资金管理服务器的支付方法的流程图；
图6是本发明实施例六提供的一种基于同一资金管理服务器的支付方法的流程图；
图7是本发明实施例七提供的一种基于同一资金管理服务器的支付装置的模块结构图；
图8是本发明实施例八提供的一种基于同一资金管理服务器的支付系统的模块结构图。
【具体实施方式】
为了使本发明所要解决的技术问题、技术方案及有益效果更加清楚、明白，以下结合附图和实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
实施例一
如图1所示，本发明实施例提供的一种基于同一资金管理服务器的支付系统，该系统包括至少一个客户端10、至少一个商户端20，信息中心服务器40和资金管理服务器30，资金管理服务器30分别与客户端10、商户端20和信息中心服务器40连接，其中：
客户端10，与资金管理服务器30相连接，用于向资金管理服务器30发送支付请求信息，其中支付请求信息包括支付金额。
具体地，客户端10适用于付款方（买方），包括手机、个人电脑、PAD等智能设备，客户端10的账户信息是用户注册时填写，并存储在资金管理服务器和/或信息中心服务器的数据库中的，客户端10的账户信息包括用户ID、开户银行、账户名称、银行账号、信用额度等信息，还可以包括客户的收货/服务地址信息。支付请求信息是在用户选择购买具体的商品/服务后，填写/确认收货/服务地址等信息，客户端10按预设的规则根据商品/服务的价格、商品/服务所属的商户生成的数据包，将该数据包发送给资金管理服务器30。支付请求信息至少包括支付金额，还可以包括商户信息和商品信息。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息（如商户ID），由资金管理服务器30根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端20的账户信息相对客户端10应该是保密的，故商户信息优选为商户ID，资金管理服务器30利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端10只需告知资金管理服务器30向哪个商户的哪个商品支付多少款项，资金管理服务器30便能调出商户的账号实现支付。
商户端20，与资金管理服务器30相连接，用于接收资金管理服务器30发送的电子承诺支付凭证。
具体地，商户端20适用于收款方（卖方），商户端包括但不限于服务器、POS机等设备。商户包括但不限于生产制造商、代理商、物流公司等。商户信息也是用户开户时进行注册并存储在资金管理服务器和/或信息中心服务器的数据库中的，商户信息包括但不限于商户ID、商户名称、商户开户银行、商户账户名称、商户银行账号等信息。
资金管理服务器30，用于接收客户端10发送的支付请求信息；根据客户端10的授信透支额度、资金余额、授信贷款额度和支付金额判断是否允许支付；如果允许支付，则冻结客户端账户内与支付金额对应的授信额度或资金，生成由所述资金管理服务器承诺按约定条件解付资金的电子承诺支付凭证，将电子承诺支付凭证信息发送给商户端20，并同步到信息中心服务器40。
具体地，资金管理服务器30接收到支付请求信息的数据包后，按预设的规则进行解析，获取相关支付信息，相关支付信息包括但不限于商户信息、商品信息和支付金额等必要信息，即向哪个商户的哪个商品支付多少款项。
信息中心服务器40，与资金管理服务器30相连，用于存储客户端10和商户端20的电子承诺支付凭证信息。
具体地，客户端10和商户端20都可以通过互联网向信息中心服务器40获取电子承诺支付凭证信息以便后继的处理，比如利用该数据进行双通道的验证信息的正确与否。资金管理服务器30还可以根据电子承诺支付凭证信息的状态进一步确定是否划款操作，即请求支付只是冻结资金，确认签收后进行划款操作。
在本实施例中，同一资金管理服务器30，还可同时与多个客户端10和多个商户端20均通过互联网连接。即商户端20账户所在的服务器与客户端10所在的服务器均为同一资金管理服务器30。同一资金管理服务器30，可以为物理意义上的单一服务器，也可以为物理意义上的多台服务器，如多台物理服务器并行工作，根据业务量的不同，自动分配服务器的资源，共同实现资金管理。资金管理服务器包括但不限于银行、企业等组织中的服务器。实际应用中，可以理解为同一银行的集群资金管理服务器，但并不局限于银行，还可以能在互联网中支持资金流动的其它机构，亦或是其他具备信用支付能力的机构，也就是通常说的第三方机构。通过资金管理服务器和信息中心服务器对买卖双方的信息进行监管，将监管功能合并到银行或其它具备信用支付能力的机构。
实施例二
如图2所示，本发明实施例提供的一种基于同一资金管理服务器的支付方法，应用于资金管理服务器，该方法包括以下步骤：
S101、资金管理服务器30接收客户端发送的支付请求信息，支付请求信息至少包括支付金额。
具体地，资金管理服务器接收的支付请求信息包括：商户信息、商品信息和支付金额，还可以包括客户端信息（如客户ID）。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息（如商户ID），由资金管理服务器根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，资金管理服务器利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端只需告知资金管理服务器向哪个商户的哪个商品支付多少款项，资金管理服务器便能调出商户的账号实施相应的支付操作。
S102、比较客户端资金余额和支付金额判断能否生成电子承诺支付凭证予以支付，如果允许支付，否则终止本次支付。
本步骤进一步包括：资金管理服务器从数据库中查询客户端的账户资金余额；判断资金余额是否大于或等于支付金额，如果是，则允许本次支付；否则终止本次支付。其中，客户端的银行账号可以是客户端在支付请求信息中告知资金管理服务器的，也可以资金管理服务器根据客户端ID从数据库中查询的，从而获取对应账户资金余额。只有在客户端的账户资金余额大于或等于支付金额时，才表示客户具有支付能力，此时才允许进行支付行为。优先采用账户资金余额支付，可以节省付款周期，保障商家的利益。
S103、资金管理服务器冻结客户端账户内与支付金额对应的资金；
具体地，当账户资金余额足以支付时，冻结银行账户内支付金额对应的资金。本步骤只冻结支付金额以确保后继有足够的资金完成本次交易，但不并直接划款到商户账号，这样保障了买卖双方的利益，后继可以由客户端、商户端或者物流公司发送解付信息确认交付完成，由资金管理服务器在接收到解付信息后，将解冻的资金划款到商户账号。
S104、资金管理服务器生成电子承诺支付凭证；
具体地，由于支付请求信息是买方通过客户端操作发送给资金管理服务器的，其支付信息客观上是得到了客户确认并授权银行支付的。资金管理服务器冻结相应的资金或授信额度，同时根据支付信息生成电子承诺支付凭证，电子承诺支付凭证信息包括但不限于商品信息、支付金额（冻结资金）、交货地址和有效期，其形式不限于文本、图片、图形码等。该电子凭证作为商户端的接收资金的凭证，商户端根据该电子承诺支付凭证提供相应的商品/服务。
S105、将电子承诺支付凭证发给商户端替客户端进行信用承诺支付并同步到信息中心服务器。
具体地，本步骤将生成的电子凭证信息发送给信息中心服务器，以便信息中心服务器进行后继跟踪。
本发明实施例的一种基于同一资金管理服务器的支付方法，通过资金管理服务器接收客户端的支付请求信息，根据买方的账户资金余额判断是否允许支付，同时通过冻结客户端账户的支付金额，并生成电子承诺支付凭证同步到信息中心服务器进行实时监控，能降低资金风险，保障买卖双方的利益。
S106、资金管理服务器接收解付信息。
资金管理服务器接收并判断解付信息是否符合约定的解付资金条件。
S107、资金管理服务器判断将解付信息同步到信息中心服务器。
S108、如解付信息符合约定的解付资金条件，资金管理服务器将资金划拨到商户端的账户。
S113、结束流程。
实施例三
如图3所示，本发明实施例提供的一种基于同一资金管理服务器的支付方法，应用于资金管理服务器，该方法包括以下步骤：
S201、资金管理服务器30接收客户端发送的支付请求信息，支付请求信息包括支付金额。
具体地，资金管理服务器接收的支付请求信息包括：商户信息、商品信息和支付金额，还可以包括客户端信息（如客户ID）。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息（如商户ID），由资金管理服务器根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，资金管理服务器利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端只需告知资金管理服务器向哪个商户的哪个商品支付多少款项，资金管理服务器便能调出商户的账号实施相应的支付操作。
S203、查询客户端账户的资金余额是否充足，如果不足，执行步骤S204，否则执行步骤S207；
S204、查询客户端账户的授信透支额度是否充足，如果不足，终止本次支付，否则执行步骤S207；
具体地，当账户资金余额足以支付时，冻结银行账户内支付金额对应的资金，当账户资金余额不足以支付，授信透支额度足以支付时，冻结银行账户内支付金额对应的授信透支额度。本步骤只冻结支付金额以确保后继有足够的资金完成本次交易，但不并直接划款到商户账号，这样保障了买卖双方的利益，后继可以由客户端、商户端或者物流公司发送解付信息确认交付完成，由资金管理服务器在接收到解付信息后，将解冻的资金划款到商户账号。
S207、冻结客户端账户内的支付金额对应的资金或授信透支额度；
S208、生成电子承诺支付凭证；
S209、将电子承诺支付凭证信息发送给商户端和信息中心服务器；
S210、商户端向资金管理服务器发送接收解付信息；
需要说明的是，本步骤S210中，商户端向资金管理服务器发送接收解付信息仅仅是一种举例，实际应用中，还可以由客户端、物流服务器或者其他能够获知交付状态的实体向资金管理服务器发送解付信息。
S211、资金管理服务器将解付信息同步到信息中心服务器。
具体地，资金管理服务器将更新的电子承诺支付凭证信息同步到信息中心服务器，从更新的电子承诺支付凭证信息可以即时获知商品的流转状态，当商品/服务交付完成后，可以将冻结的资金划款到商户的账户。
S212、将冻结的资金划拨到商户端的账户。
S213、结束流程。
本发明实施例的资金余额或授信透支余额的支付方法，通过资金管理服务器接收客户端的支付请求信息，根据买方的资金余额和授信透支余额判断是否允许支付，同时通过冻结客户端账户的支付金额，并生成电子承诺支付凭证同步到信息中心服务器进行实时监控，能降低资金风险，保障买卖双方的利益。
实施例四
如图4所示，本发明实施例提供的一种基于同一资金管理服务器的支付方法，应用于资金管理服务器，该方法该包括以下步骤：
S201、资金管理服务器30接收客户端发送的支付请求信息，支付请求信息包括支付金额。
具体地，资金管理服务器接收的支付请求信息包括：商户信息、商品信息和支付金额，还可以包括客户端信息（如客户ID）。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息（如商户ID），由资金管理服务器根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，资金管理服务器利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端只需告知资金管理服务器向哪个商户的哪个商品支付多少款项，资金管理服务器便能调出商户的账号实施相应的支付操作。
S203、查询客户端账户的资金余额是否充足，如果不足，执行步骤S205，否则执行步骤S207；
S205、查询客户端账户的授信贷款额度是否充足，如果不足，终止本次支付，否则执行步骤S207；
具体地，当账户资金余额足以支付时，冻结银行账户内与支付金额对应的资金，当账户资金余额不足以支付，授信贷款额度足以支付时，冻结银行账户内与支付金额对应的授信贷款额度。本步骤只冻结支付金额以确保后继有足够的资金完成本次交易，但不并直接划款到商户账号，这样保障了买卖双方的利益，后继可以由客户端、商户端或者物流公司发送解付信息确认交付完成，由资金管理服务器在接收到解付信息后，将解冻的资金或与授信贷款额度等额的资金划款到商户账号。
S207、冻结客户端账户内的支付金额对应的资金或授信贷款额度；
S208、生成电子承诺支付凭证；
S209、将电子承诺支付凭证信息发送给商户端和信息中心服务器；
S210、商户端向资金管理服务器发送接收解付信息；
需要说明的是，本步骤S210中，商户端向资金管理服务器发送接收解付信息仅仅是一种举例，实际应用中，还可以由客户端、物流服务器或者其他能够获知交付状态的实体向资金管理服务器发送解付信息。
S211、资金管理服务器将解付信息同步到信息中心服务器。
具体地，资金管理服务器将更新的电子承诺支付凭证信息同步到信息中心服务器，从更新的电子承诺支付凭证信息可以即时获知商品的流转状态，当商品/服务交付完成后，可以将冻结的资金划款到商户的账户。
S212、将冻结的资金划拨到商户端的账户。
S213、结束流程。
本发明实施例的资金余额或授信贷款余额的支付方法，通过资金管理服务器接收客户端的支付请求信息，根据买方的资金余额和授信贷款余额判断是否允许支付，同时通过冻结客户端账户的支付金额，并生成电子承诺支付凭证同步到信息中心服务器进行实时监控，能降低资金风险，保障买卖双方的利益。
实施例五
如图5所示，本实施例提供的一种基于同一资金管理服务器的支付方法，应用于资金管理服务器，该方法包括以下步骤：
S201、客户端向资金管理服务器发送支付请求信息，支付请求信息包括支付金额，资金管理服务器接收客户端发送的支付请求信息。
其中，支付请求信息由多个数据包组成，至少包括商户信息、商品信息和支付金额。还可以包括客户端信息（如客户ID）。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息（如商户ID），由资金管理服务器根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，资金管理服务器利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端只需告知资金管理服务器向哪个商户的哪个商品支付多少款项，资金管理服务器便能调出商户的账号实施相应的支付操作。
客户端向资金管理服务器发送支付请求信息的方式可以采用现有的方式进行，比如采用数字签名或者数字信封的方式发送。数字签名是指用户用自己的私钥对原始数据的哈希摘要进行加密所得的数据。信息接收者使用信息发送者的公钥对附在原始信息后的数字签名进行解密后获得哈希摘要，并通过与自己用收到的原始数据产生的哈希摘要对照，便可确信原始信息是否被篡改。这样就保证了数据传输的不可否认性。数字信封则采用密码技术保证了只有规定的接收人才能阅读信息的内容。数字信封中采用了单钥密码体制和公钥密码体制。信息发送者首先利用随机产生的对称密码加密信息，再利用接收方的公钥加密对称密码，被公钥加密后的对称密码被称之为数字信封。在传递信息时，信息接收方要解密信息时，必须先用自己的私钥解密数字信封，得到对称密码，才能利用对称密码解密所得到的信息。这样就保证了数据传输的真实性和完整性。
S203、查询客户端账户的资金余额是否充足，如果不足，执行步骤S204，否则执行步骤S207；
S204、查询客户端账户的授信透支额度是否充足，如果不足，执行步骤S205，否则执行步骤S207；
S205、查询客户端账户的授信贷款额度是否充足，如果不足，终止本次支付，否则执行步骤S207；
S207、冻结客户端账户内与支付金额对应的资金或授信透支余额或授信贷款余额；
S208、生成电子承诺支付凭证；
S209、将电子承诺支付凭证信息发送给商户端和信息中心服务器；
S210、商户端向资金管理服务器发送接收解付信息；
需要说明的是，本步骤S210中，商户端向资金管理服务器发送接收解付信息仅仅是一种举例，实际应用中，还可以由客户端、物流服务器或者其他能够获知交付状态的实体向资金管理服务器发送解付信息。
S211、资金管理服务器将解付信息同步到信息中心服务器。
具体地，资金管理服务器将更新的电子承诺支付凭证信息同步到信息中心服务器，当商品/服务交付完成后，可以将冻结的资金划款到商户的账户。
S212、将冻结的资金划拨到商户端的账户。
S213、结束流程。
本发明实施例，在实施例三的基础上，通过增加授信贷款额度的可选功能，不仅方便了买方，而且极大丰富了银行或其它第三方机构的贷款业务；此外，还通过增加信息中心服务器对买卖双方的电子承诺支付凭证进行同步跟踪，将商品的流转轨迹和资金的流转轨迹有效的结合，使得买卖双方的权益均能得到有效保护。
实施例六
如图6所示，本实施例提供的一种基于同一资金管理服务器的支付方法，应用于资金管理服务器，该方法包括以下步骤：
S201、客户端向资金管理服务器发送支付请求信息，支付请求信息包括支付金额，资金管理服务器接收客户端发送的支付请求信息。
其中，支付请求信息由多个数据包组成，至少包括商户信息、商品信息和支付金额。还可以包括客户端信息（如客户ID）。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息（如商户ID），由资金管理服务器根据商户唯一标识从数据库中查找商户对应的银行账号信息。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，资金管理服务器利用商户ID与其收款账号存在对应的关系来查询商户的收款账号。也就是说，客户端只需告知资金管理服务器向哪个商户的哪个商品支付多少款项，资金管理服务器便能调出商户的账号实施相应的支付操作。
客户端向资金管理服务器发送支付请求信息的方式可以采用现有的方式进行，比如采用数字签名或者数字信封的方式发送。数字签名是指用户用自己的私钥对原始数据的哈希摘要进行加密所得的数据。信息接收者使用信息发送者的公钥对附在原始信息后的数字签名进行解密后获得哈希摘要，并通过与自己用收到的原始数据产生的哈希摘要对照，便可确信原始信息是否被篡改。这样就保证了数据传输的不可否认性。数字信封则采用密码技术保证了只有规定的接收人才能阅读信息的内容。数字信封中采用了单钥密码体制和公钥密码体制。信息发送者首先利用随机产生的对称密码加密信息，再利用接收方的公钥加密对称密码，被公钥加密后的对称密码被称之为数字信封。在传递信息时，信息接收方要解密信息时，必须先用自己的私钥解密数字信封，得到对称密码，才能利用对称密码解密所得到的信息。这样就保证了数据传输的真实性和完整性。
S203、查询客户端账户的资金余额是否充足，如果不足，执行步骤S204，否则执行步骤S207；
S204、查询客户端账户的授信贷款额度是否充足，如果不足，执行步骤S204，否则执行步骤S207；
S205、查询客户端账户的授信透支额度是否充足，如果不足，终止本次支付，否则执行步骤S207；
S207、冻结客户端账户内与支付金额对应的资金或授信透支额度或授信贷款额度；
S208、生成电子承诺支付凭证；
S209、将电子承诺支付凭证信息发送给商户端和信息中心服务器；
S210、商户端向资金管理服务器发送接收解付信息；
需要说明的是，本步骤S210中，商户端向资金管理服务器发送接收解付信息仅仅是一种举例，实际应用中，还可以由客户端、物流服务器或者其他能够获知交付状态的实体向资金管理服务器发送解付信息。
S211、资金管理服务器将解付信息同步到信息中心服务器。
具体地，资金管理服务器将更新的电子承诺支付凭证信息同步到信息中心服务器，当商品/服务交付完成后，可以将冻结的资金划款到商户的账户。
S212、将冻结的资金划拨到商户端的账户。
S213、结束流程。
本发明实施例，在实施例三的基础上，通过增加授信透支额度的可选功能，不仅方便了买方，而且极大丰富了银行或其它第三方机构的信用透支业务；此外，还通过增加信息中心服务器对买卖双方的电子承诺支付凭证进行同步跟踪，将商品的流转轨迹和资金的流转轨迹有效的结合，使得买卖双方的权益均能得到有效保护。
实施例七
如图7所示，本发明实施例提供的一种支付装置，包括接收模块301、判断模块302、处理模块303，其中：
接收模块301，设置为接收客户端发送的支付请求信息，其中，支付请求信息包括支付金额。
具体地，接收模块301接收的支付请求信息包括：商户信息、商品信息和支付金额，还可以包括客户端信息（如客户ID）。其中，商户信息可以直接是商户收款账号，也可以唯一标识商户的信息（如商户ID）。在具体应用中，商户端的账户信息相对客户端应该是保密的，故商户信息优选为商户ID，也就是说，客户端只需告知资金管理服务器向哪个商户的哪个商品支付多少款项，由本装置调出商户的账号实施相应的支付操作。
判断模块302，设置为根据客户端资金余额、授信透支余额或授信贷款余额和支付金额判断是否允许支付。
作为一种优选的方案，判断模块302具体设置为：查询客户端的账户资金余额；判断客户端账户的资金余额是否大于或等于支付金额时，如果是，则允许支付；否则进一步判断客户端账户的授信透支余额是否大于或等于支付金额，如果是，则允许支付；否则再进一步判断账户资金授信贷款余额是否大于支付金额，如果是，则允许支付，否则不允许支付。如此，依次判断账户资金余额、授信透支余额和授信贷款余额的支付能力，优先采用账户资金余额支付的方式，可以节省付款周期，保障商家的利益。其中，客户端的银行账号可以是客户端在支付请求信息中告知本装置的，也可以是本装置根据客户端信息从数据库中查询的，获取对应账户资金余额、信用余额和贷款余额。只有在客户端的资金余额大于或等于支付金额时，才表示客户具有进行支付行为的能力，此时才允许进行支付行为。当采用资金管理服务器根据客户信息获取银行账号或信用卡账号时，一个客户可能有多个账号，还可以采用混合支付方式。
处理模块303，设置为当允许支付时，冻结客户端账户内与支付金额对应的资金或额度；生成电子承诺支付凭证，将电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。
优选地，处理模块303进一步包括冻结单元3031、凭证生成单元3032和同步单元3033 ，其中：
冻结单元3031，设置为当允许支付时，冻结客户端账户内的支付金额对应的资金或额度；
凭证生成单元3032，设置为生成电子承诺支付凭证；
同步单元3033，设置为将电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。
此外，处理模块303还可以包括划款单元，设置为接收到解付信息后，将解付信息同步到信息中心服务器，并将冻结的资金划拨到商户端的账户。
需要说明的是，上述方法实施例二和实施例三中的技术特征在本装置均对应适用，这里不再重述。
此外，本发明还提供了一种资金管理服务器，该资金管理服务器包括实施例四中的支付装置，这里不再重述。
本发明实施例的支付装置和服务器，通过接收客户端的支付请求信息，根据买方的资金余额、授信透支额度和授信贷款额度判断是否允许支付，同时通过冻结客户端账户的支付金额，并生成电子承诺支付凭证同步到信息中心服务器进行实时监控，能降低资金风险，保障买卖双方的利益。此外，还通过增加贷款功能，不仅方便了买方，而且极大丰富了银行或其他具备信用支付能力的机构的业务。
实施例八
如图8所示，本发明优选实施例提供的一种基于同一资金管理服务器的支付系统，该系统包括客户端10、商户端20、资金管理服务器30和信息中心服务器50，其中：
信息中心服务器50，用于存储并监管所述电子承诺支付凭证信息。
客户端10，包括支付请求模块101，设置为向资金管理服务器30发送支付请求信息，其中，支付请求信息包括：商户信息、商品信息和支付金额。
商户端20，包括凭证接收模块201和解付信息发送模块202,其中，凭证接收模块201设置为接收资金管理服务器30发送的电子承诺支付凭证。
资金管理服务器30包括接收模块301、判断模块302、和处理模块303，其中：
接收模块301，设置为接收客户端发送的支付请求信息；
判断模块302，设置为根据客户端资金余额和支付金额判断是否允许支付；
作为一种优选实施例，判断模块302设置为：判断客户端账户的资金余额是否大于或等于支付金额时，如果是，则允许支付；否则进一步判断客户端账户的授信透支余额是否大于或等于支付金额，如果是，则允许支付。
处理模块303，设置为当允许支付时，冻结客户端账户内与支付金额对应的资金或额度；生成电子承诺支付凭证，将电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。
作为一种优选实施例，资金管理服务器30的接收模块301还设置为接收解付信息；处理模块303还包括划款模块，设置为接收到解付信息后，将解付信息同步到信息中心服务器，并将冻结的资金划拨到商户端的账户。
具体地，由于支付请求信息是买方通过客户端10操作发送给资金管理服务器30的，其支付信息客观上是得到了客户端10确认并授权银行支付的。资金管理服务器30冻结相应的资金或额度，同时将生成根据支付信息生成电子承诺支付凭证，电子承诺支付凭证信息包括但不限于商品信息、支付金额（冻结资金）、交货地址和有效期，其形式不限于文本、图片、图形码等。该电子凭证作为商户端20的接收资金的凭证，商户端20根据该电子承诺支付凭证提供相应的商品/服务。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来控制相关的硬件完成，所述的程序可以在存储于一计算机可读取存储介质中，所述的存储介质，如ROM/RAM、磁盘、光盘等。
以上参照附图说明了本发明的优选实施例，并非因此局限本发明的权利范围。本领域技术人员不脱离本发明的范围和实质内所作的任何修改、等同替换和改进，均应在本发明的权利范围之内。

Claims (17)

  1. 一种基于同一资金管理服务器的支付系统，包括至少一个客户端、至少一个商户端、信息中心服务器和资金管理服务器，所述资金管理服务器分别与所述客户端、商户端和信息中心服务器连接，其中：
    所述客户端，用于向所述资金管理服务器发送至少包括有支付金额的支付请求信息；
    所述商户端，用于接收所述资金管理服务器发送的电子承诺支付凭证；
    资金管理服务器，用于接收所述客户端发送的支付请求信息；比较客户端账户资金余额和支付金额并判断能否生成电子承诺支付凭证予以支付；若能，资金管理服务器冻结所述客户端账户内与所述支付金额对应的资金，生成由所述资金管理服务器承诺按约定条件解付资金的电子承诺支付凭证，并将所述电子承诺支付凭证信息发送给商户端替所述客户端进行信用承诺支付，并将所述电子承诺支付凭证信息同步到所述信息中心服务器；
    信息中心服务器，用于存储并监管所述电子承诺支付凭证信息。
  2. 根据权利要求1所述的基于同一资金管理服务器的支付系统，其中，所述资金管理服务器为：银行的单一物理服务器或者集群服务器；或者其他具备信用支付能力的机构的单一物理服务器或者集群服务器。
  3. 权利要求1或2所述的基于同一资金管理服务器的支付系统，其中，如果客户端账户资金余额小于支付金额时，则比较客户端账户授信透支额度和支付金额并判断能否生成电子承诺支付凭证予以信用承诺支付。
  4. 根据权利要求3所述的基于同一资金管理服务器的支付系统，其中，如果客户端账户授信透支额度小于支付金额时，则比较客户端账户授信贷款额度和支付金额并判断能否生成电子承诺支付凭证予以信用承诺支付。
  5. 根据权利要求1或2所述的基于同一资金管理服务器的支付系统，其中，如果客户端账户资金余额小于支付金额时，则比较客户端账户授信贷款额度和支付金额并判断能否生成电子承诺支付凭证予以信用承诺支付。
  6. 根据权利要求5所述的基于同一资金管理服务器的支付系统，其中，如果客户端账户授信贷款额度小于支付金额时，则比较客户端账户授信透支额度和支付金额并判断能否生成电子承诺支付凭证予以信用承诺支付。
  7. 一种基于同一资金管理服务器的支付方法，该方法包括以下步骤：
    资金管理服务器接收客户端发送的支付请求信息，其中，支付请求信息至少包括支付金额；
    比较所述客户端账户资金余额和所述支付金额并判断能否生成电子承诺支付凭证予以支付；
    若能，所述资金管理服务器冻结所述客户端账户内与所述支付金额对应的资金；生成由资金管理服务器承诺按约定条件解付资金的电子承诺支付凭证，将所述电子承诺支付凭证信息发送给商户端替所述客户端进行信用承诺支付，并将所述电子承诺支付凭证信息同步到信息中心服务器。
  8. 根据权利要求7所述的基于同一资金管理服务器的支付方法，其中，如果客户端账户资金余额小于支付金额时，则比较客户端账户授信透支额度和支付金额并判断能否生成电子承诺支付凭证予以信用承诺支付。
  9. 根据权利要求8所述的基于同一资金管理服务器的支付方法，其中，如果客户端账户授信透支额度小于支付金额时，则比较客户端账户授信贷款额度和支付金额并判断能否生成电子承诺支付凭证予以信用承诺支付。
  10. 根据权利要求7所述的基于同一资金管理服务器的支付方法，其中，如果客户端账户资金余额小于支付金额时，则比较客户端账户授信贷款额度和支付金额并判断能否生成电子承诺支付凭证予以信用承诺支付。
  11. 根据权利要求10所述的基于同一资金管理服务器的支付方法，其中，如果客户端账户授信贷款额度小于支付金额时，则比较客户端账户授信透支额度和支付金额并判断能否生成电子承诺支付凭证予以信用承诺支付。
  12. 根据权利要求7所述的基于同一资金管理服务器的支付方法，其中，所述方法之前还包括：
    客户端向资金管理服务器发送支付请求信息，其中，所述支付请求信息包括：客户信息、商户信息和商品信息。
  13. 根据权利要求12中权利要求所述的基于同一资金管理服务器的支付方法，其中，所述方法之后还包括：
    资金管理服务器接收到解付信息后，将所述解付信息同步到信息中心服务器，并将所述冻结的资金划拨到所述商户端的账户。
  14. 一种基于同一资金管理服务器的支付装置，所述装置包括接收模块、判断模块和处理模块，其中：
    接收模块，设置为接收客户端发送的支付请求信息，其中，所述支付请求信息包括支付金额；
    判断模块，设置为根据所述客户端账户资金余额、授信透支余额或授信贷款余额和所述支付金额判断是否允许支付；
    处理模块，设置为当允许支付时，冻结所述客户端账户内的所述支付金额对应的资金或授信透支额度或授信贷款额度；生成电子承诺支付凭证，将所述电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。
  15. 根据权利要求14所述的支付装置，其中，所述处理模块进一步包括冻结单元、凭证生成单元和同步单元，其中：
    冻结单元，设置为当允许支付时，冻结所述客户端账户内的所述支付金额对应的资金或授信透支额度或授信贷款额度；
    凭证生成单元，设置为生成电子承诺支付凭证；
    同步单元，设置为将所述电子承诺支付凭证信息发送给商户端，并同步到信息中心服务器。
  16. 根据权利要求15所述的支付装置，其中，所述处理模块还包括划款单元，所述划款单元设置为接收到解付信息后，将解付信息同步到信息中心服务器，并将所述支付金额的资金划拨到所述商户端的账户。
  17. 一种基于同一资管理金服务器的服务器，所述服务器包括权利要求14-16任意一项权利要求所述的支付装置。
PCT/CN2015/080048 2015-04-30 2015-05-28 基于同一资金管理服务器的支付系统及方法、装置、服务器 WO2016173035A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA2987800A CA2987800A1 (en) 2015-04-30 2015-05-28 Payment system based on shared funds-management server, and method, device and server therefor

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510217988.1A CN106203975A (zh) 2015-04-30 2015-04-30 基于同一资金服务器的支付系统及其支付方法、装置和服务器
CN201510217988.1 2015-04-30

Publications (1)

Publication Number Publication Date
WO2016173035A1 true WO2016173035A1 (zh) 2016-11-03

Family

ID=57199617

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/080048 WO2016173035A1 (zh) 2015-04-30 2015-05-28 基于同一资金管理服务器的支付系统及方法、装置、服务器

Country Status (3)

Country Link
CN (1) CN106203975A (zh)
CA (1) CA2987800A1 (zh)
WO (1) WO2016173035A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113095747A (zh) * 2021-03-04 2021-07-09 支付宝(杭州)信息技术有限公司 基于区块链技术的电子提单流转方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1465027A (zh) * 2001-06-11 2003-12-31 索尼公司 电子货币系统
CN101334885A (zh) * 2008-08-06 2008-12-31 中国工商银行股份有限公司 一种基于网络的账户数据处理系统
CN102968715A (zh) * 2012-11-02 2013-03-13 汇付天下有限公司 一种基于信用数据的支付控制方法和系统
CN104200356A (zh) * 2014-08-18 2014-12-10 中国建设银行股份有限公司 适用于融资支付的数据处理系统及方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1465027A (zh) * 2001-06-11 2003-12-31 索尼公司 电子货币系统
CN101334885A (zh) * 2008-08-06 2008-12-31 中国工商银行股份有限公司 一种基于网络的账户数据处理系统
CN102968715A (zh) * 2012-11-02 2013-03-13 汇付天下有限公司 一种基于信用数据的支付控制方法和系统
CN104200356A (zh) * 2014-08-18 2014-12-10 中国建设银行股份有限公司 适用于融资支付的数据处理系统及方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113095747A (zh) * 2021-03-04 2021-07-09 支付宝(杭州)信息技术有限公司 基于区块链技术的电子提单流转方法及装置
CN113095747B (zh) * 2021-03-04 2022-05-17 支付宝(杭州)信息技术有限公司 基于区块链技术的电子提单流转方法及装置

Also Published As

Publication number Publication date
CA2987800A1 (en) 2016-11-03
CN106203975A (zh) 2016-12-07

Similar Documents

Publication Publication Date Title
Bellare et al. iKP-A Family of Secure Electronic Payment Protocols.
WO2017104899A1 (ko) 블록체인을 기반으로 하는 공인인증서 인증시스템 및 이를 이용한 인증방법
WO2016173034A1 (zh) 基于同一资金管理服务器的支付系统及方法、装置、服务器
GB2339125A (en) A mechanism for secure tendering in an open electronic network
JP2000048085A (ja) 調査情報を生成する方法および装置
WO2016173046A1 (zh) 基于同一资金管理服务器的支付系统及方法、装置、服务器
WO2016173053A1 (zh) 基于跨资金管理服务器的支付系统及其方法、装置和服务器
Kristol et al. Anonymous internet mercantile protocol
WO2017012076A1 (zh) 电子凭证收证人的确定方法、装置及系统
WO2016173043A1 (zh) 基于同一资金管理服务器的支付系统及方法、装置、服务器
WO2016173044A1 (zh) 基于跨资金管理服务器的支付系统及其方法、装置和服务器
WO2016173049A1 (zh) 基于跨资金管理服务器的支付系统及方法、装置、服务器
WO2016173051A1 (zh) 基于跨资金管理服务器的支付系统及其方法、装置和服务器
WO2016173040A1 (zh) 基于同一资金管理服务器的支付系统、方法、装置及服务器
WO2016173057A1 (zh) 基于跨资金管理服务器的支付系统及方法、装置和服务器
WO2016173050A1 (zh) 基于同一资金管理服务器的支付系统及方法、装置、服务器
WO2016173048A1 (zh) 基于同一资金管理服务器的支付系统及方法、装置、服务器
WO2016173045A1 (zh) 基于同一资金管理服务器的支付系统及方法、装置、服务器
WO2016172949A1 (zh) 基于跨资金服务器的支付系统及其支付方法、装置和服务器
JP2001160109A (ja) 情報処理装置および情報処理方法、並びに記録媒体
WO2016173035A1 (zh) 基于同一资金管理服务器的支付系统及方法、装置、服务器
WO2016173042A1 (zh) 基于跨资金管理服务器的支付系统、方法、装置及服务器
WO2016173041A1 (zh) 基于同一资金管理服务器的支付系统、方法、装置及服务器
WO2016173039A1 (zh) 基于不同资金管理服务器的支付系统、方法、装置和服务器
WO2016173037A1 (zh) 基于同一资金管理服务器的支付系统及方法、装置、服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15890414

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2987800

Country of ref document: CA

122 Ep: pct application non-entry in european phase

Ref document number: 15890414

Country of ref document: EP

Kind code of ref document: A1