WO2015175619A1 - Procédé, appareil et système pour utiliser un compte électronique en connexion avec une transaction électronique - Google Patents

Procédé, appareil et système pour utiliser un compte électronique en connexion avec une transaction électronique Download PDF

Info

Publication number
WO2015175619A1
WO2015175619A1 PCT/US2015/030499 US2015030499W WO2015175619A1 WO 2015175619 A1 WO2015175619 A1 WO 2015175619A1 US 2015030499 W US2015030499 W US 2015030499W WO 2015175619 A1 WO2015175619 A1 WO 2015175619A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
information
client terminal
upcoming
server
Prior art date
Application number
PCT/US2015/030499
Other languages
English (en)
Other versions
WO2015175619A8 (fr
Inventor
Hui Wu
Bing Wu
Qingqing Yu
Zhihui Li
Ji Xu
Min Zhang
Bo Yang
Minzhen GUO
Original Assignee
Alibaba Group Holdiing Limited
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
Priority claimed from CN201410205929.8A external-priority patent/CN105099688B/zh
Application filed by Alibaba Group Holdiing Limited filed Critical Alibaba Group Holdiing Limited
Priority to EP15724485.6A priority Critical patent/EP3143571A1/fr
Priority to KR1020197001131A priority patent/KR102218168B1/ko
Priority to JP2016562800A priority patent/JP6509253B2/ja
Priority to KR1020167028643A priority patent/KR20160134770A/ko
Publication of WO2015175619A1 publication Critical patent/WO2015175619A1/fr
Publication of WO2015175619A8 publication Critical patent/WO2015175619A8/fr

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
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3276—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being read by the M-device
    • 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
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • 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
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation

Definitions

  • the present application relates to a field of computer technology.
  • the present application relates to a method, a device, and a system for operating electronic accounts and to a method, a device, and a system for displaying payment pages.
  • FIG. 1 A is a structural block diagram of a system for performing online shopping according to some related art.
  • FIG. 1 A illustrates the devices that are generally used in connection with the user using the electronic account to perform online shopping.
  • a client terminal 101, a merchant server 102, and a payment server 103 can be used in connection with the user using the electronic account to perform online shopping.
  • the client terminal lOl can be an electronic device such as a computer or a mobile phone.
  • the merchant server 102 can be a server affiliated (e.g., hosting) with a shopping website
  • the payment server 103 can be a banking server or another server that has the authority to operate electronic accounts.
  • FIG. IB is a flowchart of a method for a user to complete a single online purchase according to some related art.
  • the client terminal 101 requests product information from the merchant server 102.
  • the merchant server 102 pushes product page information to the client terminal 101 so that a browser installed on the client terminal 101 can display a page containing various pieces of product information.
  • the user terminal 101 confirms the product information selected by the user from the page containing various pieces of product information and sends a selected product information to the merchant server 102.
  • the selected product information mentioned can be referred to as information on products that the user intends to buy.
  • the merchant server 102 pushes a payment platform display page containing payment platform information to the client terminal 101 so as to cause the client terminal 101 to display a payment platform display page containing payment platform options.
  • the payment platform is "middleware" in the transaction process between a buyer and a seller.
  • the payment platform is an independent mechanism which, under the supervision and control of a bank, safeguards the interests of both parties in a transaction.
  • a single payment platform generally corresponds to at least one payment server.
  • Payment platform options generally display the names of the payment platforms. For example, “Bank of China,” “Citibank,” or the name of a third party payment platform, and the like, are all names of payment platforms.
  • the third party payment platforms can correspond to a third party payment product such as Alipay, PayPal, Gopay, Tenpay, Otxw, Yeepay, 99bill, Baifubao, NetEase ePay, IPS, China PnR, or the like.
  • a third party payment product such as Alipay, PayPal, Gopay, Tenpay, Otxw, Yeepay, 99bill, Baifubao, NetEase ePay, IPS, China PnR, or the like.
  • the client terminal 101 sends to the merchant server 102 payment platform information corresponding to the payment platform option selected by the user.
  • the merchant server 102 sends a payment request to a corresponding payment server (e.g., the payment server 103). For example, assuming that the payment platform indicated by the payment platform information sent by the client terminal 101 corresponds to the payment server 103, then the merchant server 102 sends a payment request to payment server 103.
  • a corresponding payment server e.g., the payment server 103.
  • the payment request can include the Internet Protocol (IP) address and
  • the URL includes information on the amount to be paid and the access address for the product information selected by the user.
  • payment server 103 uses the aforesaid URL contained in the payment request as a basis for accessing the merchant server 103 and acquiring payment due information and user selected product information.
  • the payment server 103 thereupon pushes, in accordance with the IP address of the client terminal 101, a product page containing payment due information and user selected product information to the client terminal 101 so as to instruct the client terminal 101 to display this payment page.
  • 101 generally includes a payment account number input box and a payment password input box in addition to containing payment due information and user selected product information.
  • the client terminal 101 obtains the payment account number entered by the user in the payment account number input box, and the client terminal 101 obtains the payment password in the payment password input box. Moreover, the client terminal 101 sends both the payment account number and payment password that the client terminal 101 obtained to the payment server 103.
  • the payment server 103 determines whether the payment account number and payment password sent by the client terminal 101 are correctly matched. If the result of the determination at 119 as to whether the payment account number and the payment password match indicates that the payment account number and the payment password are correctly matched, then the payment server 103 proceeds to 120. Otherwise, the method 150 for a user to complete a single online purchase can be terminated.
  • the payment server 103 looks up the electronic account matched with the payment account number sent by the client terminal 101 and performs a deduction operation on the corresponding electronic account. The payment server 103 deducts the same amount as the payment due amount described above. [0021] At 121, the payment server 103 sends a notification of successful payment to the merchant server 102 to inform the merchant server 102 of the result of the current transaction.
  • the merchant server 102 sends a notification of successful payment to the client terminal 101, and the method 150 for a user to complete a single online purchase ends.
  • the payment server 103 needs to invoke a URL in order to cause the client terminal 101 to display a payment page.
  • the process of invoking a URL uses a relatively long period of processing time.
  • the client terminal 101 is required to wait for a relatively long time to complete the desired transaction.
  • the waiting time can begin with the display of the payment platform display page and end with the redirect to the display of the payment page.
  • the waiting time lowers the overall efficiency of the payment process.
  • the method 150 requires that sensitive information (e.g., the payment password) from the user be transmitted to the payment server 103 and thus runs the risk of leaking sensitive information.
  • FIG. 1 A is a structural block diagram of a system for performing online shopping according to some related art.
  • FIG. IB is a flowchart of a method for a user to complete a single online purchase according to some related art.
  • FIG. 2 is a flowchart of a method for operating an electronic account according to various embodiments of the present disclosure.
  • FIG. 3 is a flowchart of a method for using a personal mobile financial service to authorize an electronic account to pay an upcoming payment amount according to various embodiments of the present disclosure.
  • FIG. 4 is a flowchart of a method for operating an electronic account according to various embodiments of the present disclosure.
  • FIG. 5 is a flowchart of a method for operating an electronic account according to various embodiments of the present disclosure.
  • FIG. 6 is a flowchart of a method for displaying a payment page according to various embodiments of the present disclosure.
  • FIG. 7 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure.
  • FIG. 8 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure.
  • FIG. 9 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure.
  • FIG. 10 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure.
  • FIG. 11 is a structural diagram of a device for displaying a payment page according to various embodiments of the present disclosure.
  • FIG. 12 is a structural diagram of a device for displaying a payment page according to various embodiments of the present disclosure.
  • FIG. 13 is a structural block diagram of a system for processing an online transaction according to various embodiments of the present disclosure.
  • FIG. 14 is a functional diagram of a computer system for processing an online transaction according to various embodiments of the present disclosure. DETAILED DESCRIPTION
  • the invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor.
  • these implementations, or any other form that the invention may take, may be referred to as techniques.
  • the order of the steps of disclosed processes may be altered within the scope of the invention.
  • a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task.
  • the term 'processor' refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
  • Various embodiments of the present disclosure include a technique for operating electronic accounts that reduces the risk of leaking sensitive information and at the same time increases the efficiency of the payment process.
  • a device generally refers to a device used (e.g., by a user) within a network system and used to communicate with one or more servers.
  • a terminal may include communication functionality.
  • a device may be a smart phone, a tablet, a mobile phone, a video phone, an e-book reader, a desktop
  • PC Personal Computer
  • PDA Personal Digital Assistant
  • PMP Portable Multimedia Player
  • mp3 player a mobile device
  • a camera a wearable device
  • HMD Head-Mounted Device
  • electronic clothes electronic braces, an electronic necklace, an electronic accessory, an electronic tattoo, or a smart watch
  • HMD Head-Mounted Device
  • a device includes a smart home appliance with communication functionality.
  • a smart home appliance can be, for example, a television, a Digital Video Disk (DVD) player, an audio device, a refrigerator, an air conditioner, a vacuum cleaner, an oven, a microwave oven, a washer, a dryer, an air purifier, a set-top box, a TV box (e.g., Samsung HomeSyncTM, Apple TVTM, or Google TVTM), a gaming console, an electronic dictionary, an electronic key, a camcorder, an electronic picture frame, or the like.
  • DVD Digital Video Disk
  • a device can be any combination of the foregoing devices.
  • a device according to various embodiments of the present disclosure is not limited to the foregoing devices.
  • a terminal such as a client terminal can correspond to a device.
  • FIG. 2 is a flowchart of a method for operating an electronic account according to various embodiments of the present disclosure.
  • a method 200 for operating an electronic account is provided.
  • process 200 can be implemented by device 700 of FIG. 7. In some embodiments, process 200 can be implemented by device 800 of FIG. 8. In some embodiments, process 200 can be implemented by device 900 of FIG. 9. In some embodiments, process 200 can be implemented by device 1000 of FIG. 10. In some embodiments, process 200 can be
  • a payment platform display page acquisition request is received.
  • a merchant server receives the payment platform display page acquisition request.
  • the merchant server can be a server affiliated with an electronic commerce website (e.g., a website on which goods or services can be purchased).
  • the merchant server can be a server that hosts an electronic commerce website.
  • the merchant server can receive a payment platform display page acquisition request from a first client terminal.
  • the first client terminal can send the payment platform display page acquisition request to the merchant server in connection with an online purchase.
  • the payment platform display page acquisition request can be sent in connection with a checkout process associated with the electronic commerce website, an electronic commerce server such as a service accessed through an application, or the like.
  • a payment platform display page is provided.
  • the merchant server provides the payment platform display page.
  • the merchant server can provide (e.g., send) the payment platform display page to the first client terminal in response to the merchant server receiving the payment platform display page acquisition request.
  • a first script code can be embedded in the payment platform display page.
  • the merchant server can generate the first script code and generate, or otherwise configure, the payment platform display page to include the first script code.
  • the payment platform display page can be configured to cause a recipient terminal (e.g., the first client terminal) to execute the first script code.
  • the payment platform display page can cause the first client terminal to execute the first script code in response to the first client terminal accessing the payment platform display page (e.g., when the first client terminal views the payment platform display page in a browser installed on the first client terminal).
  • the first script code can be a program that accompanies an HTML page (e.g., the payment platform display page).
  • the first script code can be JavaScript (JS) or the like.
  • the file script code is configured to cause the first client terminal to acquire a payment page that includes a digital object unique identifier from a payment server and to display the payment page (e.g., in response to the first client terminal receiving the payment page).
  • the first script code can redirect the first client terminal to the payment server.
  • the payment server is a server that is affiliated with a financial institution, financial transaction processing service, or the like.
  • the payment server can be a banking server or another server that has the authority to operate electronic accounts.
  • the payment server can debit and credit an electronic account.
  • the first script code includes location information (e.g., the storage address) of a second script code at the payment server.
  • the first client terminal can first execute the first script code and thereby acquire from the payment server the second script file code.
  • the second script file code can be a program stored on the payment server or on a storage unit associated with the payment server.
  • the second script file code can be JavaScript or the like.
  • the second script file code can be configured to cause the first client terminal to communicate payment information to the payment server.
  • the first client terminal executes the second script file code to send upcoming payment sum information to the payment server.
  • the payment server receives the upcoming payment sum information (e.g., from the first client terminal)
  • the payment server can generate a digital object unique identifier representing the upcoming payment sum associated with the upcoming payment sum information.
  • the second script file code in response to being executed by the first client terminal, triggers the payment server to generate the digital object unique identifier.
  • the payment server can send the digital object unique identifier representing the upcoming payment sum to the first client terminal.
  • the payment server can send the digital object unique identifier in connection with a payment page.
  • the payment page can include the digital object unique identifier.
  • the first client terminal receives a payment page including the digital object unique identifier from the payment server, the first client terminal can display the payment page.
  • the digital object unique identifier can, in addition to indicating the upcoming payment sum, indicate information of the product that is to be purchased.
  • the digital object unique identifier can include product information corresponding to a product that is associated with a transaction corresponding to the upcoming payment sum.
  • the "upcoming payment sum" corresponds to information on the sum that is to be paid using an electronic account.
  • the upcoming payment sum can be represented by a digital object unique identifier.
  • the digital object unique identifier is associated with, or otherwise represents, the upcoming payment sum, product information, information on the seller of the product, any other appropriate information, or any combination thereof.
  • the "digital object unique identifier" can be an identifier that uniquely identifies an electronic document.
  • the digital object unique identifier can be an identifier used by a digital document producer to uniquely identify an electronic document published by the digital document producer.
  • DOUIs can be generated by a device such as the payment server using existing library functions and/or application programming interface (API) calls.
  • API application programming interface
  • a DOUI encodes the upcoming payment sum as well as any other appropriate transaction information.
  • Metadata associated with the digital object is stored in association with the digital object unique identifier name.
  • the metadata can include a location, such as a URL, where the digital object can be found.
  • the digital object unique identifier associated with a document remains fixed over the lifetime of the document. However, the location and other metadata can change.
  • the digital object unique identifier is a character string. Identifiers for many applications under various environments have been subsequently formed on the basis of the digital object unique identifier.
  • the digital object unique identifier corresponds to two-dimensional codes, barcodes, or the like.
  • the payment server can send two-dimensional code to the first user terminal so that the first user terminal displays the two-dimensional code.
  • a second client terminal can acquire the two- dimensional code from the first client terminal.
  • a second client terminal can scan, or otherwise receive, the two-dimensional code.
  • the second client can scan the two-dimensional code that is displayed by the first client terminal.
  • the second client terminal can determine the upcoming payment sum information represented by the two-dimensional code.
  • the second client terminal uses the two-dimensional code to confirm information associated with the transaction corresponding to the two-dimensional code (e.g., the transaction associated with the upcoming payment sum information represented by the two-dimensional code). For example, the second client terminal can extract transaction
  • the second client terminal can provide (e.g., display) transaction information, such as the upcoming payment sum information, to a user.
  • the user can confirm the upcoming payment sum
  • the user can confirm that the transaction (e.g., the transaction corresponding to the two-dimensional code) is accurate or approved for payment.
  • the transaction e.g., the transaction corresponding to the two-dimensional code
  • the second client terminal can send confirmation of the transaction to the payment server.
  • the second client terminal can send confirmation of the transaction (e.g., the upcoming payment sum information) to the payment server.
  • verification information is received.
  • the merchant server receives verification information.
  • the payment server can send the verification information to the merchant server.
  • the payment server can generate the verification information in response to receiving confirmation of the upcoming payment sum information from the second user terminal. For example, in the event that the user confirms the transaction (e.g., the upcoming payment sum information) on the second client terminal, the payment server can generate the verification information.
  • the second client terminal uses a personal mobile financial service to authorize an electronic account to pay the upcoming payment sum, thereupon triggering the payment server to issue (e.g., generate) the verification information.
  • the verification information can be an electronic signature.
  • the electronic signature can correspond to data which in electronic form is included in, or attached to, a datagram and is used to identify the signatory and to indicate that the signatory approves the content thereof.
  • the electronic signature includes payment server identity information and the upcoming payment sum information.
  • the electronic signature includes information on the product corresponding to the upcoming payment sum information, information on the seller of the product, information on an authorized electronic account, or the like.
  • an instruction to execute a deduction operation on an authorized electronic account is communicated.
  • the verification information can be submitted by a user in connection with an instruction to execute the deduction operation on the authorized electronic account.
  • the merchant server can send the instruction to execute the deduction operation on the authorized account to the payment server.
  • the payment server is registered with the merchant server
  • the payment server's identification information is stored at a secure location on the merchant server.
  • the merchant server can trigger the payment server to perform a deduction operation on the electronic account.
  • the merchant server can trigger the payment server to perform a deduction operation on the electronic account by sending the electronic signature to the payment server.
  • a financial institution or the like can provide personal mobile financial services to a user.
  • the user can use a client terminal (e.g., a mobile terminal) to interface with the financial institution in connection with the providing of the personal mobile financial services.
  • a client terminal e.g., a mobile terminal
  • personal mobile financial services correspond to the linking of client terminal identifying information (e.g., cell phone numbers, or the like) with electronic accounts and providing mobile communication network users who own electronic accounts with convenient, personalized financial services and rapid payment channels anytime, anywhere through text messaging (e.g., Short Messaging Service (SMS) messages, Multimedia Messaging Service (MMS) messages), instant messages, or other such cell phone operations.
  • client terminal identifying information e.g., cell phone numbers, or the like
  • MMS Multimedia Messaging Service
  • instant messages e.g., instant messages, or other such cell phone operations.
  • the personal mobile financial services include account recharging, telephone recharging services, mobile phone lottery tickets, mobile phone donations, mobile phone shopping, and electronic account balance inquiries.
  • a user uses a mobile terminal in connection with mobile phone shopping that makes use of a personal mobile financial service
  • a user after confirming an upcoming payment sum, triggers (e.g., instructs) a mobile device to send to a mobile
  • the communications network side (e.g., the payment server) a verification code acquisition request including the upcoming payment sum, the mobile phone number, and an identifier (e.g., a bank card number) of an electronic account associated with the user's mobile phone number.
  • the mobile communications network side can include the payment server.
  • a message e.g., a short message
  • the user can submit the verification code into a verification code input box of the payment platform display page and click the "OK" option to trigger the mobile device to send the verification code to the mobile communications network side.
  • the mobile communications network determines that execution of the upcoming payment using the electronic account indicated by the bank card number has been authorized.
  • the mobile communications network side pushes an authorization response message indicating successful authorization to the mobile device.
  • the user can use the mobile device to request, or otherwise authorize, that the payment server perform a deduction operation on the electronic account.
  • the process of authorizing the payment server to perform the deduction operation on the electronic account does not require the sending of sensitive information such as a payment password to the network. Accordingly, various embodiments lower the risk of a leak of sensitive information.
  • FIG. 3 is a flowchart of a method for using a personal mobile financial service to authorize an electronic account to pay an upcoming payment amount according to various embodiments of the present disclosure.
  • process 300 can be implemented by device 700 of FIG. 7.
  • process 300 can be implemented by device 800 of FIG. 8.
  • process 300 can be implemented by device 900 of FIG. 9.
  • process 300 can be implemented by device 1000 of FIG. 10.
  • process 300 can be implemented by system 1300 of FIG. 13.
  • a personal mobile financial service is activated.
  • a user activates a personal mobile financial service that links a second client terminal (e.g., mobile device) to a bank card number.
  • the user can register an account with a personal mobile financial service.
  • a purchase is initiated over a network.
  • a user can use a client terminal to purchase a product or service.
  • a user uses the first client terminal to access an electronic commerce website to select the product that the user wishes to purchase, and selects to pay for the purchase using a mobile device wallet.
  • the user can click the "Use mobile phone wallet to pay" option provided by the electronic commerce website.
  • a two-dimensional code acquisition request is communicated.
  • the first client terminal sends a two-dimensional code acquisition request to the payment server.
  • the two-dimensional code acquisition request includes transaction information, such as the upcoming payment sum information.
  • a two-dimensional code is acquired.
  • the first client terminal receives the two-dimensional code from the payment server.
  • the two-dimensional code corresponds to the transaction (e.g., the purchase from the electronic commerce website).
  • the payment server uses the upcoming payment sum information included in the two-dimensional code acquisition request to generate, or otherwise acquire, two-dimensional code information including upcoming payment sum information.
  • the payment server sends the two-dimensional code information (e.g., the two-dimensional code) to the first client terminal.
  • the payment server can send the two-dimensional code information to the first client terminal by including the two-dimensional code information in a web page, an application, an email, a text message (e.g., an SMS message, an MMS message), the like, or any combination thereof.
  • a two-dimensional code information is provided.
  • the second client terminal receives the two-dimensional code from the first client terminal.
  • the first client terminal receives the two-dimensional code from the payment server, extracts the two- dimensional code from the received two-dimensional code information, and provides the two- dimensional code to the user (e.g., to the second client terminal).
  • the first client terminal can provide the two-dimensional code to the user (e.g., to the second client terminal).
  • the first client terminal displays a two-dimensional code according to the received two-dimensional code information.
  • the first client terminal can send the two-dimensional code to the second client terminal.
  • the first client terminal can send the two-dimensional code to the second client terminal over a wired or wireless connection.
  • the wireless connection can correspond to a Bluetooth connection, a WiFi connection, a Near Field Communication (NFC) connection, an infrared connection, the like, or any combination thereof.
  • transaction information is obtained from the two-dimensional code.
  • the second client terminal receives the two-dimensional code from the first client terminal.
  • the second client terminal can scan, or otherwise capture, the two-dimensional code displayed by the first client terminal.
  • transaction information e.g., upcoming payment sum information
  • the second client terminal can process the two-dimensional code to obtain a string comprising the upcoming payment sum and thereby obtain (e.g., extract) the upcoming payment sum information from the two- dimensional code.
  • a verification code acquisition request is communicated.
  • the second client terminal can send the verification code acquisition request to the mobile communications network.
  • the second client terminal can send the verification code acquisition request to the payment server.
  • the verification code acquisition request includes the upcoming payment sum, the mobile phone number (e.g., of the second client terminal), a bank card number associated with the mobile phone number, an account associated with the mobile phone number, the like, or any combination thereof.
  • account information is verified.
  • a mobile phone In some embodiments, a mobile phone
  • the communications network side (e.g., the payment server) verifies the association between the mobile phone number and the bank card number (or other account information). For example, in response to receiving the verification code acquisition request, the payment server can extract information from the verification code acquisition request that is used to verify account information (e.g., the mobile phone number and the bank card number). The mobile communications network side can verify the upcoming payment sum. In some embodiments, in the event that the upcoming payment sum exceeds a threshold value associated with a permissible payment amount, the upcoming payment sum will fail verification. In some embodiments, in the event that the upcoming payment does not exceed the threshold value associated with the permissible payment amount, the upcoming payment sum will pass verification.
  • the threshold value associated with the permissible payment amount can be configured by a user (e.g., according to user preferences), by a financial institution (e.g., the financial institution associated with the account), a payment processing service, the like, or any combination thereof.
  • an authorization response message is communicated.
  • the authorization response message can be communicated from the mobile communications network side (e.g., payment server) to the second client terminal.
  • the authorization response message can be configured according to whether the account information is verified at 340. For example, the authorization response message can be sent to the second client terminal only if the account information is verified.
  • the mobile communications network side After the mobile communications network side verifies the upcoming payment sum and the above-described link between the mobile phone number and the bank card number, the mobile communications network side sends to the second client terminal an authorization response message indicating that the transaction is to be completed using the transaction information (e.g., information included in the verification code acquisition request).
  • the authorization response message can indicate that "payment for the upcoming payment sum is to be made from the electronic account indicated by the authorized bank card number.”
  • the authorization response message in the event that the account information is not verified (e.g., if verification of the account information fails), the authorization response message can be configured to indicate that verification failed.
  • an authorization response message is communicated to the payment server.
  • the second client terminal sends an authorization response message to the payment server to inform the payment server that a deduction operation can be performed on the electronic account associated with the bank card number.
  • the authorization response message sent by the second client terminal to the payment server can correspond to a confirmation to complete the transaction (e.g., payment) using the corresponding transaction information (e.g., information included in the verification code acquisition request).
  • the payment server can issue the verification information described in connection with 230 of process 200 of FIG. 2.
  • the payment server can send the verification information to the merchant server.
  • the authorization response message communicated at 345 can be the same as the authorization response message communicated at 350.
  • the merchant server can send the received verification information to the payment server to instruct the payment server to execute a deduction operation on the authorized electronic account.
  • the communication of the received verification information in connection with instructing the payment server to execute the deduction operation on the authorized electronic account can be implemented according to various processes.
  • the verification information includes electronic account information and upcoming payment sum information.
  • the payment server can execute a deduction operation on the electronic account according to the electronic account information and upcoming payment sum information included in the verification information.
  • the verification information includes a transaction serial number that is generated by the payment server when the transaction is initiated, and an authorization notification includes the transaction serial number, electronic account information, and upcoming payment sum information.
  • the verification information and the authorization notification can be associated according to the corresponding transaction serial number.
  • the payment server can identify corresponding verification information and authorization notification according to matching transaction serial numbers respectively included therein.
  • the payment server can store a mapping of verification information to a corresponding authorization notification.
  • the payment server can use the transaction serial number, electronic account information, and upcoming payment sum information included in the authorization notification to establish mapping relationships between transaction serial numbers, electronic account information, and upcoming payment sum information, the like, or any combination thereof.
  • the payment server can use the mapping relationships of transaction serial numbers, electronic account information, and upcoming payment sum information to acquire the transaction serial number included in the verification information received from the merchant server.
  • the payment server can use the mapping relationships of transaction serial numbers, electronic account information, and upcoming payment sum information to look up the electronic account information and upcoming payment sum information which are mapped from the transaction serial number.
  • the payment server can perform a deduction operation on an electronic account using the electronic account information and upcoming payment sum information which are mapped from the transaction serial number. For example, the payment server performs a deduction operation on the electronic account according to the electronic account information and the upcoming payment sum information that were looked up in connection with the transaction serial number included in the verification information.
  • the electronic account associated with a deduction operation is determined according to information sent by the second client terminal. For example, in the event that the second client terminal uses a personal mobile financial service to authorize an electronic account to pay the upcoming payment sum, the electronic account information can be carried in the authorization notification or in another message sent to the payment server.
  • Various embodiments of the present disclosure provide a method, an apparatus, and a system according to which a client terminal can use a personal mobile financial service to authorize an electronic account to pay an upcoming payment sum, such that the authorization process does not require transmission of sensitive information such as a payment password or the like. Therefore, the authorization process can reduce the risk of leaks of sensitive information. Additionally, because the authorization process to authorize an electronic account to pay an upcoming payment sum according to various embodiments requires only that the user execute a script file code embedded in a payment platform display page, acquiring the display page from the payment server displaying the page without the payment server having to invoke a URL is relatively simple. As a result, the payment process according to various embodiments is efficient. In some embodiments, the payment process uses the verification message sent by the merchant server as a trigger condition for executing the deduction operation on the electronic account. Thus, in some embodiments, the merchant server can actively control the timing of the deduction operation performed on the electronic account.
  • 210-240 of process 200 illustrated in FIG. 2 can be implemented by a merchant server. In some embodiments, 210-240 of process 200 can be implemented by the same merchant server. In some embodiments, 210 and 220 of process 200 can be implemented by a first merchant server, and 230 and 240 of process 200 can be implemented by a second merchant server. The first merchant server and the second merchant server can be different merchant servers. In some embodiments, various other devices can implement any of 210-240 of process 200. In some embodiments, the first client terminal and the second client terminal described in connection with process 200 and process 300 can be implemented by the same client terminal. [0094] Various embodiments provide a method, an apparatus, and a system for operating electronic accounts. The electronic accounts can be operated or managed to reduce the risk of leaking sensitive information while also increasing the efficiency of the payment process.
  • FIG. 4 is a flowchart of a method for operating an electronic account according to various embodiments of the present disclosure.
  • a method 400 for operating an electronic account is provided.
  • process 400 can be implemented by device 700 of FIG. 7. In some embodiments, process 400 can be implemented by device 800 of FIG. 8. In some embodiments, process 400 can be implemented by device 900 of FIG. 9. In some embodiments, process 400 can be implemented by device 1000 of FIG. 10. In some embodiments, process 400 can be
  • a digital object unique identifier acquisition request is received.
  • a payment server receives the payment platform display page acquisition request.
  • the payment server is a server that is affiliated with a financial institution, financial transaction processing service, or the like.
  • the payment server can be a banking server or another server that is connected to a bank's account database and has the authority to operate electronic accounts.
  • the payment server is configured to receive the digital object unique identifier acquisition request sent by a first client terminal.
  • the digital object unique identifier acquisition request is sent by the first client terminal in connection with the execution of a first script code embedded in a payment platform display page.
  • a first script code embedded in a payment platform display page.
  • the first client terminal can be caused to execute the first script code, which causes the first client terminal to send, to the payment server, the digital object unique identifier acquisition request.
  • the first script code can be a program that accompanies an HTML page (e.g., the payment platform display page).
  • the first script code can be JavaScript or the like.
  • the first client terminal can send a code acquisition request to a payment server by executing the first script code.
  • the payment server can provide the first client terminal with a second script file code.
  • the first client terminal receives the second script file code (e.g., from the payment server)
  • the first client terminal can execute the second script file code.
  • the first user terminal can send a digital object unique identifier acquisition request to the payment server.
  • the second script file code can cause the first client terminal to send a digital object unique identifier acquisition request to the payment server.
  • a payment page including the digital object unique identifier is provided.
  • the payment server provides the first client terminal with a payment page including the digital object unique identifier.
  • the payment page can be an HTML page, a page for an application installed on the first client terminal, or the like.
  • the digital object unique identifier indicates the upcoming payment sum.
  • the digital object unique identifier can include other transaction information associated with an online transaction (e.g., product information associated with a purchase from an electronic commerce website, identification information of an electronic commerce server such as a service accessed through an application, or the like).
  • verification information is provided.
  • the payment server provides the verification information to a merchant server.
  • the payment server can send the verification information in response to the payment server receiving the authorization notification.
  • the authorization notification can be sent to the payment server by a second client terminal.
  • the first client terminal can display the digital object unique identifier or information included therein to a user of the first client terminal.
  • the first client terminal can extract the upcoming payment sum included in the digital object unique identifier.
  • the second client terminal can acquire the upcoming payment sum or confirmation of the upcoming payment sum.
  • the second client terminal can capture the digital object unique identifier or the information included in the digital object unique identifier.
  • the second client terminal can capture the digital object unique identifier or the information included in the digital object unique identifier using image capture, or via a user manually entering the
  • the second client terminal can provide an interface through which a user can confirm the upcoming payment sum.
  • the second client terminal can use a personal mobile financial service to authorize an electronic account to pay the upcoming payment sum and thereupon send the authorization notification.
  • a deduction operation is performed on a corresponding electronic account.
  • the payment server can perform the deduction operation on the electronic account. For example, in response to receiving the verification information sent by the merchant server, the payment server can execute a deduction operation on the electronic account associated with the verification information.
  • the verification information includes electronic account information and upcoming payment sum information.
  • the merchant server can send the verification information to the payment server.
  • the merchant server can send the verification information to the payment server to instruct the payment server to execute a deduction operation on the electronic account according to the electronic account information and the upcoming payment sum information included in the verification information.
  • the verification information includes a transaction serial number.
  • the merchant server can send the verification information to the payment server.
  • the payment server can search for the electronic account information and the upcoming payment sum information corresponding to information included in the verification information.
  • the merchant server can send the verification information to the payment server to instruct the payment server to use pre- established mapping relationships between the transaction serial number, the electronic account information, and the upcoming payment sum information to look up the electronic account information and the upcoming payment sum information mapped from the transaction serial number included in the verification information, and to execute a deduction operation on the electronic account according to the electronic account information and the upcoming payment sum information that were looked up.
  • Various embodiments of the present disclosure use a personal mobile financial service to authorize an electronic account to pay an upcoming payment sum such that transmission of sensitive information is not required in order to complete authorization to pay the upcoming payment sum. Therefore, the authorization can reduce the risk that sensitive information will be leaked. Additionally, because the authorization process to authorize an electronic account to pay an upcoming payment sum according to various embodiments requires only that the user execute a script file code embedded in a payment platform display page, acquiring the display page from the payment server and displaying the page without the payment server having to invoke a URL is relatively simple. As a result, the payment process according to various embodiments is relatively simple. [0108] In some embodiments, 410-440 of process 400 illustrated in FIG. 4 can be implemented by a payment server.
  • 410-440 of process 400 can be implemented by the same payment server.
  • 410 of process 400 can be implemented by a first payment server
  • 420-440 of process 400 can be implemented by a second payment server.
  • the first payment server and the second payment server can be different payment servers.
  • various other devices can implement any of 410-440 of process 400.
  • the first client terminal and the second client terminal described in connection with process 400 can be implemented by the same client terminal.
  • FIG. 5 is a flowchart of a method for operating an electronic account according to various embodiments of the present disclosure.
  • a method 500 for operating an electronic account is provided.
  • process 500 can be implemented by device 700 of FIG. 7. In some embodiments, process 500 can be implemented by device 800 of FIG. 8. In some embodiments, process 500 can be implemented by device 900 of FIG. 9. In some embodiments, process 500 can be implemented by device 1000 of FIG. 10. In some embodiments, process 500 can be
  • a user 501 selects to complete an electronic purchase on a first client terminal 502 (e.g., a personal computer).
  • the user 501 can select to complete the electronic purchase on a website in a browser installed on the first client terminal 502.
  • the user 501 can select to complete the electronic purchase in an application installed on the first client terminal 502.
  • the electronic purchase can relate to a purchase of a product or service offered for sale by an electronic commerce website, electronic commerce service, or the like.
  • the user 501 can click a "Buy Now" in connection with the electronic purchase.
  • the first client terminal 502 can be instructed to open (e.g., navigate to) a payment platform display page.
  • a request for a payment platform display page is communicated.
  • the first client terminal 502 sends a request for the payment platform display page to a merchant server 503.
  • the first client terminal 502 can request the payment platform display page from the merchant server 503 in response to the user 501 selecting to complete the electronic purchase.
  • the merchant server 503 can be a server affiliated with an electronic commerce website (e.g., a website on which goods or services can be purchased).
  • the merchant server 503 can be a server that hosts an electronic commerce website, electronic commerce service, or the like.
  • the request is sent as an HTTP GET message directed to the URL of the payment platform display page.
  • the request for the payment platform display page is communicated using a proprietary protocol. HTTP-based communication is described below for purposes of example although other protocols can be used.
  • a first script code is embedded in a payment platform display page.
  • the merchant server 503 embeds the first script code in the payment platform display page.
  • the first script code can be JS or the like.
  • the merchant server 503 determines the payment platform display page including upcoming payment sum information and information on the product that is to be purchased and embeds a piece of JS code in the payment platform display page.
  • the merchant server 503 can configure the first script code (e.g., the JS code) using transaction information.
  • the merchant server 503 can configure the script code using transaction information associated with the request for the payment platform display page.
  • the transaction information can include the upcoming payment sum information, product information, seller information, the like, or any combination thereof.
  • JS is a language that can be embedded in an HTML page.
  • JS code is a language that can be embedded in an HTML page.
  • JS code is a language that can be embedded in an HTML page.
  • the JS code can be embedded in the payment platform display page data.
  • the JS code is invoked by the browser (or the application) to interact with the web page client (e.g., in response to the payment platform display page being accessed by the corresponding browser or other application on a client terminal).
  • the first script code (e.g., the piece of JS code) includes a payment server address associated with a payment server 504.
  • the first client terminal 502 is triggered (e.g., caused by the script code to execute) to send a payment page module acquisition request to the payment server indicated by the payment server address.
  • the first script code can redirect the browser or application of the first client terminal 502 to the payment server address.
  • the payment page module associated with the payment page module acquisition request can correspond to a function module implemented by software.
  • a payment platform display page is communicated.
  • the merchant server 503 communicates the payment platform display page to the first client terminal 502.
  • the merchant server 503 pushes the requested payment platform display page to the first client computer in response to receiving the request for a payment platform display page.
  • the payment platform display page can have the first script code embedded therein.
  • the payment platform display page is displayed.
  • the first client terminal 502 in response to receiving the payment platform display page, the first client terminal 502 renders the payment platform display page in the browser.
  • the browser of first client terminal 502 can execute the first script code embedded in the payment platform display page in connection with the rendering of the payment platform display page.
  • a request for a payment page module is communicated.
  • the first client terminal 502 can send a payment page module acquisition request to a payment server 504 indicated by the payment server address included in the first script code.
  • the first client terminal 502 can send the payment page module acquisition request to the payment server 504 in response to the first client terminal 502 executing the first script code.
  • 515 and 516 of process 500 are executed asynchronously.
  • a second script code is generated.
  • the payment server 504 generates the second script code.
  • the payment server 504 can generate the second script code in response to receiving the request for the payment page module.
  • the second script code can be JS or the like.
  • the second script code generated by the payment server 504 implements the payment page module functions.
  • the second script code is communicated.
  • the payment server 504 sends the second script code to the first client terminal 502.
  • a payment platform option can be rendered.
  • the second script code causes the payment platform option to be rendered.
  • the first client terminal 502 renders payment platform options on the payment platform display page.
  • the payment platform option rendered in connection with executing the second script code can correspond to a payment platform associated with the payment server 504 (e.g., the payment server that generated the second script code).
  • the first client terminal 502 can render the payment platform option
  • the payment platform display page is displayed.
  • the requested payment platform display page is displayed by the first client terminal 502.
  • the first client terminal 502 can display the payment platform display page including the payment platform options.
  • a payment platform option is selected.
  • the payment platform option is selected by the user 501.
  • the user 501 can input the selection to the first client terminal 502. For example, the user 501 can click a payment platform option displayed on the payment platform display page.
  • a request for generation of a two-dimensional code is communicated.
  • the first client terminal 502 communicates a two-dimensional code generation request in response to selection of the payment platform option. For example, by executing the second JS code, the first client terminal 502 sends a two-dimensional code generation request to the payment server 504 corresponding to the payment platform option selected (e.g., clicked) by the user 501.
  • the two-dimensional code generation request includes upcoming payment sum information and information on the product to be purchased.
  • two-dimensional code information is generated.
  • the payment server 504 in the event that the payment server 504 receives the two-dimensional code information, the payment server 504 generates the two-dimensional code information.
  • the payment server 504 can generate the two-dimensional code information according to the upcoming payment sum information and information on the product to be purchased included in the two-dimensional generation request.
  • the generated two-dimensional code information includes upcoming payment sum information, information on the product to be purchased, and information used to render a page associated with completing an electronic purchase.
  • the information used to render a page associated with completing an electronic purchase can include information used to render a "Checkout.”
  • the "Checkout" can correspond to a page including a "Confirm Payment” option.
  • the two-dimensional code information can include a two-dimensional code.
  • the two-dimensional code can include the upcoming payment sum information, the information on the product to be purchased, and the information used to render a page associated with completing an electronic purchase.
  • a two-dimensional code information address is communicated.
  • the payment server 504 sends the two-dimensional code information address to the first client terminal 502.
  • the two-dimensional code information address can correspond to a URL at which the two-dimensional code information can be accessed, or otherwise retrieved.
  • the payment server 504 can send the generated two-dimensional code information address (e.g., URL) to the first client terminal 502 in response to the payment server 504 receiving the two-dimensional code generation request.
  • the two dimensional code information is acquired.
  • the two-dimensional code information is acquired (e.g., downloaded) from the two-dimensional code information address.
  • the first client terminal 502 can download the two- dimensional code information from the two-dimensional code information address.
  • the client terminal 502 can download the two-dimensional code information from the payment server 504 according to the two-dimensional code information URL in connection with executing the second script code.
  • the second script code can cause the first client terminal 502 to automatically download the two-dimensional code information.
  • a two-dimensional code is displayed.
  • the first client terminal 502 displays the two-dimensional code.
  • the first client terminal 502 can extract, or otherwise acquire, the two-dimensional code from the two-dimensional code information that is downloaded from the two-dimensional code information address.
  • the two-dimensional code is acquired.
  • the user 501 acquires the two-dimensional code from the first client terminal 502.
  • the user 501 can use a second client terminal 505 (e.g., a mobile phone) to scan the two-dimensional code displayed by the first client terminal 502.
  • the second client terminal 505 can scan the two- dimensional code using an image capture function (e.g., a camera function of the mobile device).
  • the user 501 can manually input information included in the two-dimensional code to the second client terminal 505.
  • the two-dimensional code can be provided to the user 501 (via the second client terminal 505) over a wired or wireless connection rather than via a display.
  • the second client terminal 505 can extract, from the two-dimensional code, the upcoming payment sum information, the information on the product to be purchased, and the information used to render a page associated with completing an electronic purchase. For example, the second client terminal 505 can obtain the upcoming payment sum information, the information on the product to be purchased, and information for rendering a "Checkout.”
  • the second client terminal 505 renders a page associated with completing an electronic purchase.
  • the second client terminal 505 can use the upcoming payment sum information, the information on the product to be purchased, and the information for rendering a "Checkout" as a basis to display a page including the upcoming payment sum, the information on the product to be purchased, and information associated with confirmation of a payment (e.g., a "Confirm Payment" option).
  • the information associated with confirmation of a payment included in the page can be an interface through which the user 501 can confirm payment in connection with the purchase of the product to be purchased.
  • the page can be displayed in a browser, an
  • the payment in connection with the purchase of the product to be purchased is confirmed.
  • the user 501 can input confirmation of the payment through the page displayed on the second client terminal 505. After confirming that the upcoming payment sum and the information on the product to be purchased are free of error, the user 501 can select (e.g., click) the "Confirm Payment” option. In the event that the user 501 confirms the payment (e.g., the user 501 selects the "Confirm Payment" option), the second client terminal 505 can send a verification code request to the mobile communications network side (e.g., the payment server, an authentication server, or the like).
  • the mobile communications network side e.g., the payment server, an authentication server, or the like.
  • the verification code request can include the upcoming payment sum, the phone number of the second client terminal 505, and a bank card number associated with the phone number.
  • the mobile communications network side verifies the upcoming payment sum and the association between the mobile phone number and the bank card number
  • the mobile communications network side pushes a verification code to the second client terminal 505.
  • the user 501 can input the verification code into the second client terminal 505.
  • the mobile communication network side e.g., the payment server 504
  • SMS Short Message Service
  • the second client terminal 505 can send the verification code to the mobile communications network side.
  • the mobile communications side can send an authorization response message to the second client terminal 505.
  • the authorization response message can indicate that the authorization was successful.
  • an authorization notification is communicated.
  • the second client terminal 505 sends the authorization notification to the payment server 504.
  • the authorization notification can include information associated with the authorized electronic account.
  • the authorization notification can include the electronic account information indicated by the bank card number.
  • the payment server 503 is queried as to whether the transaction is authorized.
  • the first client terminal 502 can query the payment server 504 as to whether the upcoming payment sum has been authorized for payment.
  • the user 501 can manually control the first client terminal 502 to query the payment server 504.
  • the first client terminal 502 can automatically query the payment server 504 at predetermined intervals. For example, by executing the second script code, the first client terminal 502 can periodically query the payment server 504 on whether the upcoming payment sum has been authorized for payment.
  • the two-dimensional information generated by the payment server 504 can include a transaction serial number.
  • the transaction serial number can be associated with the upcoming payment sum information and the information on the product to be purchased, and the transaction serial number can be used to uniquely identify the transaction.
  • the verification acquisition request, the authorization response message, and the authorization notification all can include the transaction serial number.
  • the first client terminal 502 can use the transaction serial number as a basis for querying whether the upcoming payment sum has been authorized for payment. For example, the first client terminal 502 can send a query request including the transaction serial number to the payment server 504 to trigger the payment server 504 to determine whether an authorization notification including the transaction serial number has been received. In the event that the payment server 504 determines that the authorization notification including the transaction serial number has been received, then payment server 504 can send an indication that the transaction is authorized to the first client terminal 502. Accordingly, the first client terminal 502 can determine that the upcoming payment sum has been authorized for payment.
  • the first client terminal 502 determines that the upcoming payment sum has not been authorized for payment.
  • a payment token is communicated.
  • the payment server 504 sends the payment token to the first client terminal 502.
  • the payment server 504 can send a payment token to the first client terminal 502.
  • the payment token is a unique token (e.g., an alphanumeric string).
  • the payment token can be one kind of the verification information.
  • the payment token includes an electronic signature and transaction serial number from the payment server 504.
  • the payment token can be generated by the payment server 504.
  • the payment token can include an electronic signature of the payment server 504.
  • the payment server 504 can locally establish mapping relationships between the transaction serial number, upcoming payment sum information, and information on the authorized electronic account after confirming that the upcoming payment sum has been authorized for payment.
  • the payment token is communicated to the merchant server 503.
  • the first client terminal 502 can send the payment token to the merchant server 503.
  • the payment token is communicated to the payment server 504.
  • the merchant server 503 can send the payment token to the payment server 504 in connection with receiving payment for the electronic purchase.
  • the merchant server 503 can exchange the payment token for payment with the payment server 504.
  • the merchant server 503 sends the payment token to the payment server 504.
  • a deduction operation on the authorized electronic account is executed.
  • the payment server 504 receives the payment token (e.g., from the merchant server 503)
  • the payment server 504 executes a deduction operation on the authorized electronic account saved in correspondence with the transaction serial number in the payment token.
  • the payment server 504 can perform a verification process to verify the payment token (e.g., to verify the authenticity of the payment token).
  • the payment server 504 can verify the payment server signature in the payment token.
  • the payment server 504 can determine whether the signature from a payment server that is included in the payment token matches the signature of the payment server 504.
  • the payment server 504 executes a deduction operation on the authorized electronic account saved in correspondence with the transaction serial number in the payment token.
  • the sum that is specifically deducted in connection with the deduction operation corresponds to the upcoming payment sum indicated by the upcoming payment information mapped from the transaction serial number in the payment token determined according to the mapping relationships locally established by the payment server between the transaction serial number, the upcoming payment sum information, and the information on the authorized electronic account.
  • a status notification of the funds deduction is communicated.
  • the payment server 504 communicates the notification of the successful funds deduction in response to successfully executing the deduction operation (e.g., the deduction operation at 535), or the notification of a failed funds deduction in response to a failed attempt at executing the deduction operation.
  • the payment server 504 can send the notification of the successful funds deduction to the merchant server 503.
  • a status notification of a payment is communicated.
  • the merchant server 503 instructs the first client terminal 502 to display a notification of successful or failed payment.
  • the notification of successful or failed payment can be communicated to the first client terminal 502.
  • the first client terminal 502 can display a notification that the payment was successful or unsuccessful to the user 501.
  • the first client terminal 502 can provide an alert to the user 501 in the event that payment is successful or unsuccessful.
  • the alert can be a notification provided by displaying the status information in text, a popup window showing the status, changing a brightness of a display, providing an alert via a sound, an indicator light, a vibration, the like, or any combination thereof.
  • the merchant server 503 communicates the status notification of payment to the second client terminal 505.
  • the notification of payment can be concurrently communicated to the first client terminal 502 and the second client terminal 505.
  • the second client terminal 505 can display a notification that the payment was successful or unsuccessful to the user 501.
  • the second client terminal 505 can provide an alert to the user 501 in the event that payment is successful or unsuccessful.
  • the alert can be a notification provided by displaying a popup, changing a brightness of a display, providing an alert via a sound, an indicator light, a vibration, the like, or any combination thereof.
  • FIG. 6 is a flowchart of a method for displaying a payment page according to various embodiments of the present disclosure.
  • process 600 can be implemented by device 700 of FIG. 7. In some embodiments, process 600 can be implemented by device 700 of FIG. 7. In some embodiments,
  • process 600 can be implemented by device 800 of FIG. 8. In some embodiments, process 600 can be implemented by device 900 of FIG. 9. In some embodiments, process 600 can be implemented by device 1000 of FIG. 10. In some embodiments, process 600 can be
  • a payment platform display page acquisition request is communicated.
  • the first client terminal sends the payment platform display page acquisition request to a merchant server.
  • a payment platform display page is obtained.
  • the first client terminal can obtain the payment platform display page.
  • the first client terminal can receive the payment platform display page from the merchant server.
  • the payment platform display page has a first script code embedded therein.
  • the first script code can be JS or the like.
  • the first script code can be a program that accompanies an HTML page (e.g., the payment platform display page).
  • the file script file code can be configured to cause the first client terminal to acquire a payment page that includes a digital object unique identifier from a payment server and to display the payment page (e.g., in response to the first client terminal receiving the payment page).
  • the first script code can redirect the first client terminal to the payment server.
  • the first script code is executed.
  • the first client terminal executes the first script code.
  • the first client terminal in response to receiving the payment platform display page, can execute the first script code.
  • the first script code can be embedded in the payment platform display page such that in the event that the payment platform display page is accessed (e.g., rendered, or otherwise displayed), the first script code is executed.
  • the first client terminal executes the first script code and thereby acquires a payment page including a digital object unique identifier from a payment server and displays the payment page.
  • the second client terminal can execute an operation such that, upon confirming the upcoming payment sum indicated by the digital object unique identifier displayed by the first client terminal in connection with displaying the payment page, the second client terminal uses a personal mobile financial service to authorize an electronic account to pay the upcoming payment sum.
  • the first script code includes a storage address of a second script file code in a payment server.
  • the first client terminal can execute the first script code and thereby acquire the second script code from the payment server.
  • the second script code can be JS or the like.
  • the first client terminal can execute the second script code and thereby sends the upcoming payment sum information to the payment server and acquires a payment page including the digital object unique identifier from the payment server and displays the payment page.
  • 610-630 of process 600 illustrated in FIG. 6 can be implemented by a client terminal. In some embodiments, 610-630 of process 600 can be implemented by the same client terminal. In some embodiments, 610 of process 600 can be implemented by a first client terminal, and 620 and 630 of process 600 can be implemented by a second client terminal. The first client terminal and the second client terminal can be different merchant servers. In some embodiments, various other devices can implement any of 610-630 of process 600.
  • FIG. 7 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure.
  • a device 700 configured to operate an electronic account.
  • device 700 is used to implement at least a part of method 200 of FIG. 2.
  • device 700 is used to implement at least a part of method 300 of FIG. 3.
  • device 700 is used to implement at least a part of method 400 of FIG. 4.
  • device 700 is used to implement at least a part of method 500 of FIG. 5.
  • device 700 can be implemented by system 1300 of FIG. 13.
  • the device 700 is implemented in a merchant server.
  • the device 700 includes a request receiving module 710, a page information sending module 720, an information receiving module 730, and a verification information sending module 740.
  • the request receiving module 710 is configured to receive a payment platform display page acquisition request.
  • the request receiving module 710 can receive the payment platform display page acquisition request from a first client terminal.
  • the page information sending module 720 is configured to provide a payment platform display page in which is embedded a first script code.
  • the page information sending module provides (e.g., communicates) to the first client terminal a payment platform display page.
  • the payment platform display page can have a first script code embedded therein.
  • the first script code can be JS or the like.
  • the first script code can be a program that accompanies an HTML page (e.g., the payment platform display page).
  • the file script file code can be configured to cause the first client terminal to acquire a payment page that includes a digital object unique identifier from a payment server and to display the payment page (e.g., in response to the first client terminal receiving the payment page).
  • the first script code can redirect the first client terminal to the payment server.
  • the digital object unique identifier at least indicates the upcoming payment sum.
  • the information receiving module 730 is configured to receive verification information.
  • the payment server can issue the verification information.
  • the verification information is issued after a second client terminal confirms the upcoming payment sum indicated by the digital object unique identifier displayed by the first client terminal, and the second client terminal uses a personal mobile financial service to authorize an electronic account to pay the upcoming payment sum, thereupon triggering the payment server to issue the verification information.
  • the verification information sending module 740 is configured to communicate the verification information.
  • the verification information sending module 740 can send the verification information to the payment server.
  • the verification information sending module 740 can send the verification information received by the information receiving module 730 to the payment server to instruct the payment server to execute a deduction operation on the electronic account.
  • FIG. 8 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure.
  • a device 800 configured to operate an electronic account.
  • device 800 is used to implement at least a part of method 200 of FIG. 2.
  • device 800 is used to implement at least a part of method 300 of FIG. 3.
  • device 800 is used to implement at least a part of method 400 of FIG. 4.
  • device 800 is used to implement at least a part of method 500 of FIG. 5.
  • device 800 can be implemented by system 1300 of FIG. 13.
  • the device 800 is implemented in a merchant server.
  • device 800 includes a signal receiver 810, a processor 820, and a signal transmitter 830.
  • the signal receiver 810 is configured to receive a payment platform display page acquisition request sent by a first client terminal or verification information sent by a payment server.
  • the verification information is issued after a second client terminal confirms the upcoming payment sum indicated by the digital object unique identifier displayed by the first client terminal, and the second client terminal uses a personal mobile financial service to authorize an electronic account to pay the upcoming payment sum, thereupon triggering the payment server to issue the verification information.
  • the processor 820 is configured to control the signal transmitter 830 to provide the first client terminal with a payment platform display page in which is embedded a first script code.
  • the processor 820 can control the signal transmitter 830 to provide the first client terminal with a payment platform display page.
  • the payment platform display page can have a first script code embedded therein.
  • the first script code can be JS or the like.
  • the first script code can be a program that accompanies an HTML page (e.g., the payment platform display page).
  • the file script code can be configured to cause the first client terminal to acquire a payment page that includes a digital object unique identifier from a payment server and to display the payment page (e.g., in response to the first client terminal receiving the payment page). For example, the first script code can redirect the first client terminal to the payment server.
  • the digital object unique identifier at least indicates the upcoming payment sum.
  • the signal transmitter 830 is configured to provide, under the control of the processor 820, the first client terminal with a payment platform display page in which a first script code is embedded. In some embodiments, the signal transmitter 830 is configured to send the verification information received by the signal receiver 810 to the payment server to instruct the payment server to execute a deduction operation on an electronic account.
  • FIG. 9 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure.
  • a device 900 configured to operate an electronic account is provided.
  • device 900 is used to implement at least a part of method 200 of FIG. 2.
  • device 900 is used to implement at least a part of method 300 of FIG. 3.
  • device 900 is used to implement at least a part of method 400 of FIG. 4.
  • device 900 is used to implement at least a part of method 500 of FIG. 5.
  • device 900 can be implemented by system 1300 of FIG. 13.
  • the device 900 is implemented in a payment server.
  • the device 900 includes a request receiving module 910, a page providing module 920, a message receiving module 930, an information sending module 940, an information receiving module 950, and an operation executing module 960.
  • the request receiving module 910 is configured to receive a digital object unique identifier acquisition request sent by a first client terminal.
  • the digital object unique identifier acquisition request can be sent by the first client terminal executing a first script code embedded in a payment platform display page.
  • the page providing module 920 is configured to provide a payment page including a digital object unique identifier to the first client terminal.
  • the page providing module 920 can send the payment page to the first client terminal in the event that the request receiving module 910 has received the digital object unique identifier acquisition request.
  • the message receiving module 930 is configured to receive an authorization notification sent by a second client terminal.
  • the authorization notification can be sent to the message receiving module 930 in the event that the second client terminal confirms the upcoming payment sum indicated by the digital object unique identifier displayed by the first client terminal, and the second client terminal can use a personal mobile financial service to authorize an electronic account to pay the upcoming payment sum and thereupon the authorization notification is sent to the message receiving module 930.
  • the information sending module 940 is configured to send verification information to a merchant server.
  • the information sending module 940 can send the verification information to the merchant server in the event that the message receiving module 930 receives the authorization notification.
  • the information receiving module 950 is configured to receive the verification information sent by the merchant server.
  • the operation executing module 960 is configured to execute a deduction operation on the electronic account.
  • the operation executing module 960 can execute the deduction operation on the electronic account in the event that the information receiving module 950 receives the verification information.
  • FIG. 10 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure.
  • a device 1000 configured to operate an electronic account.
  • device 1000 is used to implement at least a part of method 200 of FIG. 2.
  • device 1000 is used to implement at least a part of method 300 of FIG. 3.
  • device 1000 is used to implement at least a part of method 400 of FIG. 4.
  • device 1000 is used to implement at least a part of method 500 of FIG. 5.
  • device 1000 can be implemented by system 1300 of FIG. 13.
  • the device 1000 is implemented in a payment server.
  • the device 1000 includes a signal receiver 1010, a signal transmitter 1020, and a processor 1030.
  • the signal receiver 1010 is configured to receive a digital object unique identifier acquisition request sent by a first client terminal, receive an authorization notification sent by a second client terminal, and verification information sent by a merchant server.
  • the digital object unique identifier acquisition request can be sent by the first client terminal in the event that the first client terminal executes a first script code embedded in a payment platform display page.
  • the authorization notification can be sent in the event that the second client terminal confirms the upcoming payment sum indicated by the digital object unique identifier displayed by the first client terminal, and the second client terminal uses a personal mobile financial service to authorize an electronic account to pay the upcoming payment sum and thereupon send the authorization notification.
  • the signal transmitter 1020 is configured to provide a payment page including a digital object unique identifier to the first client terminal.
  • the signal transmitter can send the digital object unique identifier in the event that the signal receiver 1010 has received the digital object unique identifier acquisition request.
  • the signal receiver 1010 can send the verification information to the merchant server.
  • a deduction operation is executed on the electronic account.
  • the processor 1030 can execute the deduction operation on the electronic account.
  • FIG. 11 is a structural diagram of a device for displaying a payment page according to various embodiments of the present disclosure.
  • a device 1100 configured to display a payment page.
  • device 1100 is used to implement at least a part of method 200 of FIG. 2.
  • device 1100 is used to implement at least a part of method 300 of FIG. 3.
  • device 1100 is used to implement at least a part of method 400 of FIG. 4.
  • device 1100 is used to implement at least a part of method 500 of FIG. 5.
  • device 1100 can be implemented by system 1300 of FIG. 13.
  • the device 1100 is implemented in a client terminal.
  • the device 1100 includes a sending module 1110, an information obtaining module 1120, and a payment page displaying module 1130.
  • the sending module 1110 is configured to send a payment platform display page acquisition request to a merchant server.
  • the information obtaining module 1120 is configured to obtain from the merchant server the payment platform display page in which a first script code is embedded.
  • the information obtaining module 1120 can obtain the payment platform display page in the event that the request sending module 1110 sends the payment platform display page acquisition request.
  • the first script code can be JS or the like.
  • the first script code can be a program that accompanies an HTML page (e.g., the payment platform display page).
  • the file script file code can be configured to cause a client terminal to acquire a payment page that includes a digital object unique identifier from a payment server and to display the payment page (e.g., in response to the first client terminal receiving the payment page).
  • the first script code can redirect the client terminal to the payment server.
  • the payment page displaying module 1130 is configured to execute the first script code embedded in the payment platform display page obtained by the information obtaining module 1120 and thereby acquire a payment page containing a digital object unique identifier from a payment server and display the payment page.
  • a personal mobile financial service can be used to authorize an electronic account to pay the upcoming payment.
  • a user can use the personal mobile financial service to authorize the electronic account to pay the upcoming payment.
  • the user can use a client terminal to access the personal mobile financial service.
  • FIG. 12 is a structural diagram of a device for displaying a payment page according to various embodiments of the present disclosure.
  • a device 1200 configured to display a payment page.
  • device 1200 is used to implement at least a part of method 200 of FIG. 2.
  • device 1200 is used to implement at least a part of method 300 of FIG. 3.
  • device 1200 is used to implement at least a part of method 400 of FIG. 4.
  • device 1200 is used to implement at least a part of method 500 of FIG. 5.
  • device 1200 can be implemented by system 1300 of FIG. 13.
  • the device 1200 is implemented in a client terminal.
  • the device 1200 includes a signal transmitter 1210, an information collector 1220, a processor 1230, and an information display device 1240.
  • the signal transmitter 1210 is configured to send a payment platform display page acquisition request to a merchant server.
  • the information collector 1220 is configured to obtain a payment platform display page in which a first script code is embedded.
  • the first script code can be JS or the like.
  • the first script code can be a program that accompanies an HTML page (e.g., the payment platform display page).
  • the file script file code can be configured to cause a client terminal to acquire a payment page that includes a digital object unique identifier from a payment server and to display the payment page (e.g., in response to the first client terminal receiving the payment page).
  • the first script code can redirect the client terminal to the payment server.
  • the information collector 1220 can obtain the payment platform display page in the event that the signal transmitter 1210 has sent a payment platform display page acquisition request.
  • the information collector is configured to acquire, under the control of the processor 1230, a payment page including a digital object unique identifier from a payment server.
  • the processor 1230 is configured to execute the first script code and thereby control the information collector 1220 to acquire the payment page including the digital object unique identifier from the payment server.
  • the information display device 1240 is configured to display the payment page including the digital object unique identifier acquired by the information collector 1220.
  • a user of the device 1200 can confirm the upcoming payment sum indicated by the digital object unique identifier that is displayed.
  • the upcoming payment sum indicated by the digital object unique identifier that is displayed can be confirmed using a personal mobile financial service to authorize an electronic account to pay the upcoming payment.
  • FIG. 13 is a structural block diagram of a system for processing an online transaction according to various embodiments of the present disclosure.
  • a system 1300 for processing an online transaction is provided.
  • system 1300 implements the method 200 of FIG. 2. In some embodiments, the system 1300 implements the method 200 of FIG. 2. In some embodiments, the system 1300 implements the method 200 of FIG. 2. In some embodiments, the system 1300 implements the method 200 of FIG. 2. In some embodiments, the system 1300 implements the method 200 of FIG. 2. In some embodiments, the system 1300 implements the method 200 of FIG. 2.
  • the system 1300 implements the method 300 of FIG. 3. In some embodiments, the system 1300 implements the method 400 of FIG. 4. In some embodiments, the system 1300 implements the method 500 of FIG. 5. In some embodiments, the system 1300 implements the method 600 of FIG. 6. In some embodiments, the system 1300 implements the device 700 of FIG. 7. In some embodiments, the system 1300 implements the device 800 of FIG. 8. In some embodiments, the system 1300 implements the device 900 of FIG. 9. In some embodiments, the system 1300 implements the device 1000 of FIG. 10. In some embodiments, the system 1300 implements the device 1100 of FIG. 11. In some embodiments, the system 1300 implements the device 1200 of FIG. 12.
  • the system 1300 for processing an online transaction includes a first client terminal
  • the system 1300 can include a network 1350 over which the first client terminal 1310, the second client terminal 1320, the merchant server 1330, and the payment server 1340 can communicate.
  • the network 1350 can be a LAN, a Wide Area Network (WAN), the Internet, or the like.
  • the various devices of the system 1300 e.g., devices 1310, 1320, 1330, and 1340
  • can communicate over a direct connection between one another e.g., a WiFi Direct connection, a Bluetooth connection, an infrared connection, or the like).
  • FIG. 14 is a functional diagram of a computer system for processing an online transaction according to various embodiments of the present disclosure.
  • Computer system 1400 for processing an online transaction is provided.
  • Computer system 1400 which includes various subsystems as described below, includes at least one microprocessor subsystem (also referred to as a processor or a central processing unit (CPU)) 1402.
  • processor 1402 can be implemented by a single-chip processor or by multiple processors.
  • processor 1402 is a general purpose digital processor that controls the operation of the computer system 1400. Using instructions retrieved from memory 1410, the processor 1402 controls the reception and manipulation of input data, and the output and display of data on output devices (e.g., display 1418).
  • Processor 1402 is coupled bi-directionally with memory 1410, which can include a first primary storage, typically a random access memory (RAM), and a second primary storage area, typically a read-only memory (ROM).
  • primary storage can be used as a general storage area and as scratch-pad memory, and can also be used to store input data and processed data.
  • Primary storage can also store programming instructions and data, in the form of data objects and text objects, in addition to other data and instructions for processes operating on processor 1402.
  • primary storage typically includes basic operating instructions, program code, data, and objects used by the processor 1402 to perform its functions (e.g., programmed instructions).
  • memory 1410 can include any suitable computer- readable storage media, described below, depending on whether, for example, data access needs to be bi-directional or uni-directional.
  • processor 1402 can also directly and very rapidly retrieve and store frequently needed data in a cache memory (not shown).
  • the memory can be a non-transitory computer-readable storage medium.
  • a removable mass storage device 1412 provides additional data storage capacity for the computer system 1400, and is coupled either bi-directionally (read/write) or uni-directionally (read only) to processor 1402.
  • storage 1412 can also include computer-readable media such as magnetic tape, flash memory, PC-CARDS, portable mass storage devices, holographic storage devices, and other storage devices.
  • a fixed mass storage 1420 can also, for example, provide additional data storage capacity. The most common example of mass storage 1420 is a hard disk drive.
  • Mass storage device 1412 and fixed mass storage 1420 generally store additional programming instructions, data, and the like that typically are not in active use by the processor 1402. It will be appreciated that the information retained within mass storage device 1412 and fixed mass storage 1420 can be incorporated, if needed, in standard fashion as part of memory 1410 (e.g., RAM) as virtual memory.
  • bus 1414 can also be used to provide access to other subsystems and devices. As shown, these can include a display monitor 1418, a network interface 1416, a keyboard 1404, and a pointing device 1406, as well as an auxiliary input/output device interface, a sound card, speakers, and other subsystems as needed.
  • the pointing device 1406 can be a mouse, stylus, track ball, or tablet, and is useful for interacting with a graphical user interface.
  • the network interface 1416 allows processor 1402 to be coupled to another computer, computer network, or telecommunications network using a network connection as shown.
  • the processor 1402 can receive information (e.g., data objects or program instructions) from another network or output information to another network in the course of performing method/process steps.
  • Information often represented as a sequence of instructions to be executed on a processor, can be received from and outputted to another network.
  • An interface card or similar device and appropriate software implemented by (e.g., executed/performed on) processor 1402 can be used to connect the computer system 1400 to an external network and transfer data according to standard protocols.
  • various process embodiments disclosed herein can be executed on processor 1402, or can be performed across a network such as the Internet, intranet networks, or local area networks, in conjunction with a remote processor that shares a portion of the processing.
  • Additional mass storage devices can also be connected to processor 1402 through network interface 1416.
  • auxiliary I/O device interface (not shown) can be used in conjunction with computer system 1400.
  • the auxiliary I/O device interface can include general and customized interfaces that allow the processor 1402 to send and, more typically, receive data from other devices such as microphones, touch-sensitive displays, transducer card readers, tape readers, voice or handwriting recognizers, biometrics readers, cameras, portable mass storage devices, and other computers.
  • the computer system shown in FIG. 14 is but an example of a computer system suitable for use with the various embodiments disclosed herein. Other computer systems suitable for such use can include additional or fewer subsystems.
  • bus 1414 is illustrative of any interconnection scheme serving to link the subsystems. Other computer architectures having different configurations of subsystems can also be utilized.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Conformément à des modes de réalisation, la présente invention concerne un procédé, un appareil et un système pour utiliser un compte électronique ou afficher une page de paiement. Le procédé consiste à recevoir, d'un premier terminal de client, une requête d'acquisition de page d'affichage de plate-forme de paiement, à fournir, au premier terminal de client, une page d'affichage de plate-forme de paiement, la page d'affichage de plate-forme de paiement comprenant un premier code de script, dans le cas dans lequel le premier code de script est exécuté, le premier code de script amenant le premier terminal de client à obtenir, d'un serveur de paiement, une page de paiement comprenant un identificateur unique d'objet numérique et à afficher la page de paiement, l'identificateur unique d'objet numérique indiquant la prochaine somme de paiement, à recevoir des informations de vérification et à envoyer les informations de vérification au serveur de paiement pour donner l'instruction au serveur de paiement d'exécuter une opération de déduction sur un compte électronique.
PCT/US2015/030499 2014-05-15 2015-05-13 Procédé, appareil et système pour utiliser un compte électronique en connexion avec une transaction électronique WO2015175619A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP15724485.6A EP3143571A1 (fr) 2014-05-15 2015-05-13 Procédé, appareil et système pour utiliser un compte électronique en connexion avec une transaction électronique
KR1020197001131A KR102218168B1 (ko) 2014-05-15 2015-05-13 전자 트랜잭션과 관련되어 전자 계좌를 동작시키기 위한 방법, 장치, 및 시스템
JP2016562800A JP6509253B2 (ja) 2014-05-15 2015-05-13 電子取引に関連して電子口座を操作するための方法、装置、および、システム
KR1020167028643A KR20160134770A (ko) 2014-05-15 2015-05-13 전자 트랜잭션과 관련되어 전자 계좌를 동작시키기 위한 방법, 장치, 및 시스템

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201410205929.8 2014-05-15
CN201410205929.8A CN105099688B (zh) 2014-05-15 2014-05-15 一种电子账户的操作方法、支付页面的展示方法及装置
US14/710,075 2015-05-12
US14/710,075 US10902393B2 (en) 2014-05-15 2015-05-12 Method, apparatus, and system for operating an electronic account in connection with an electronic transaction

Publications (2)

Publication Number Publication Date
WO2015175619A1 true WO2015175619A1 (fr) 2015-11-19
WO2015175619A8 WO2015175619A8 (fr) 2016-10-20

Family

ID=53264822

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/030499 WO2015175619A1 (fr) 2014-05-15 2015-05-13 Procédé, appareil et système pour utiliser un compte électronique en connexion avec une transaction électronique

Country Status (1)

Country Link
WO (1) WO2015175619A1 (fr)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106204047A (zh) * 2016-06-30 2016-12-07 成都生辉电子科技有限公司 一种移动终端支付装置
CN108805559A (zh) * 2018-07-25 2018-11-13 努比亚技术有限公司 二维码推送方法、移动终端及计算机可读存储介质
JP2019500703A (ja) * 2015-12-29 2019-01-10 アリババ グループ ホウルディング リミテッド バーコードベースのモバイル決済及びサービス処理の方法及び装置
CN109801075A (zh) * 2019-01-02 2019-05-24 深圳壹账通智能科技有限公司 支付方法、装置、计算机设备和存储介质
CN110663053A (zh) * 2017-05-22 2020-01-07 区块链控股有限公司 将未确定来源的未确定数据安全地提供到区块链交易的锁定脚本中
JP2020501280A (ja) * 2016-12-12 2020-01-16 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ リソース割当方法及び装置並びに電子決済方法
CN112348503A (zh) * 2020-11-24 2021-02-09 中国农业银行股份有限公司安徽省分行 资金代收付方法
CN113435880A (zh) * 2021-07-12 2021-09-24 支付宝(杭州)信息技术有限公司 一种基于聚合码的支付页面发送方法、装置、设备及介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012073014A1 (fr) * 2010-11-29 2012-06-07 Mobay Technologies Limited Système pour vérifier des transactions électroniques
US20120209749A1 (en) * 2011-02-16 2012-08-16 Ayman Hammad Snap mobile payment apparatuses, methods and systems
US20130219479A1 (en) * 2012-02-17 2013-08-22 Daniel B. DeSoto Login Using QR Code

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012073014A1 (fr) * 2010-11-29 2012-06-07 Mobay Technologies Limited Système pour vérifier des transactions électroniques
US20120209749A1 (en) * 2011-02-16 2012-08-16 Ayman Hammad Snap mobile payment apparatuses, methods and systems
US20130219479A1 (en) * 2012-02-17 2013-08-22 Daniel B. DeSoto Login Using QR Code

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019500703A (ja) * 2015-12-29 2019-01-10 アリババ グループ ホウルディング リミテッド バーコードベースのモバイル決済及びサービス処理の方法及び装置
US11282063B2 (en) 2015-12-29 2022-03-22 Advanced New Technologies Co., Ltd. Method and apparatus of barcode-based mobile processing
CN106204047A (zh) * 2016-06-30 2016-12-07 成都生辉电子科技有限公司 一种移动终端支付装置
US11734667B2 (en) 2016-12-12 2023-08-22 Advanced New Technologies Co., Ltd. Resource allocation method and device, and electronic payment method
JP2020501280A (ja) * 2016-12-12 2020-01-16 アリババ・グループ・ホールディング・リミテッドＡｌｉｂａｂａ Ｇｒｏｕｐ Ｈｏｌｄｉｎｇ Ｌｉｍｉｔｅｄ リソース割当方法及び装置並びに電子決済方法
US11222327B2 (en) 2016-12-12 2022-01-11 Advanced New Technologies Co., Ltd. Resource allocation method and device, and electronic payment method
CN110663053A (zh) * 2017-05-22 2020-01-07 区块链控股有限公司 将未确定来源的未确定数据安全地提供到区块链交易的锁定脚本中
CN110663053B (zh) * 2017-05-22 2024-06-07 区块链控股有限公司 将未确定来源的未确定数据安全地提供到区块链交易的锁定脚本中
CN108805559A (zh) * 2018-07-25 2018-11-13 努比亚技术有限公司 二维码推送方法、移动终端及计算机可读存储介质
CN108805559B (zh) * 2018-07-25 2023-12-15 努比亚技术有限公司 二维码推送方法、移动终端及计算机可读存储介质
CN109801075A (zh) * 2019-01-02 2019-05-24 深圳壹账通智能科技有限公司 支付方法、装置、计算机设备和存储介质
CN112348503B (zh) * 2020-11-24 2023-11-03 中国农业银行股份有限公司安徽省分行 资金代收付方法
CN112348503A (zh) * 2020-11-24 2021-02-09 中国农业银行股份有限公司安徽省分行 资金代收付方法
CN113435880B (zh) * 2021-07-12 2023-06-30 支付宝（中国）网络技术有限公司 一种基于聚合码的支付页面发送方法、装置、设备及介质
CN113435880A (zh) * 2021-07-12 2021-09-24 支付宝(杭州)信息技术有限公司 一种基于聚合码的支付页面发送方法、装置、设备及介质

Also Published As

Publication number Publication date
WO2015175619A8 (fr) 2016-10-20

Similar Documents

Publication Publication Date Title
US20210073761A1 (en) Method, apparatus, and system for operating an electronic account in connection with an electronic transaction
KR102141836B1 (ko) 이중 인증
US20210150506A1 (en) Peer-to-peer payment systems and methods
WO2015175619A1 (fr) Procédé, appareil et système pour utiliser un compte électronique en connexion avec une transaction électronique
CN107533708B (zh) 跨应用程序统一登录
US9639174B2 (en) Mobile device display content based on shaking the device
AU2019253872A1 (en) Seamless transaction minimizing user input
US9824357B2 (en) Focus-based challenge-response authentication
US9825955B2 (en) Method and system for exchanging information
US20120290468A1 (en) Method and apparatus for secure payment using a network-connectable device
WO2015088853A1 (fr) Lancement d'une application client basée sur un message
US20210333861A1 (en) Hands-free gestures for account authentication
CN109102266B (zh) 账户数值转移方法及装置
WO2019125552A1 (fr) Fourniture d'affichages optimisés sur des interfaces utilisateur sur la base de listes d'articles générés par un utilisateur
CN114096981A (zh) 利用支付卡认证语音交易
WO2018118248A1 (fr) Procédé et système de pré-contrôle d'achat
EP3617982A1 (fr) Systèmes et procédés assurant un remplissage automatique par clavier virtuel
US10592898B2 (en) Obtaining a signature from a remote user
US20160005023A1 (en) Conducting financial transactions by telephone
US11301360B2 (en) System and method for using an unobtrusive and discrete embedded barcode for debugging
WO2019025868A1 (fr) Système et procédé de fourniture de services sécurisés
RU2630166C1 (ru) Система, способ и устройство для осуществления онлайн платежей с использованием платежных карт
NL2025516B1 (en) Methods and systems for transferring funds
KR102394694B1 (ko) 결제 서버, 결제 시스템 및 그 카드 등록 방법
WO2016033144A1 (fr) Procédé et système d'échange d'informations

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: 15724485

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2015724485

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015724485

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20167028643

Country of ref document: KR

Kind code of ref document: A

Ref document number: 2016562800

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE