US20210073761A1 - Method, apparatus, and system for operating an electronic account in connection with an electronic transaction - Google Patents
Method, apparatus, and system for operating an electronic account in connection with an electronic transaction Download PDFInfo
- Publication number
- US20210073761A1 US20210073761A1 US16/951,901 US202016951901A US2021073761A1 US 20210073761 A1 US20210073761 A1 US 20210073761A1 US 202016951901 A US202016951901 A US 202016951901A US 2021073761 A1 US2021073761 A1 US 2021073761A1
- Authority
- US
- United States
- Prior art keywords
- payment
- client terminal
- information
- server
- upcoming
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 147
- 238000012795 verification Methods 0.000 claims abstract description 124
- 230000004044 response Effects 0.000 claims description 68
- 238000013475 authorization Methods 0.000 claims description 57
- 238000012790 confirmation Methods 0.000 claims description 21
- 238000013507 mapping Methods 0.000 claims description 8
- 238000004590 computer program Methods 0.000 claims description 7
- 230000008569 process Effects 0.000 description 67
- 238000010295 mobile communication Methods 0.000 description 19
- 238000010586 diagram Methods 0.000 description 18
- 238000012545 processing Methods 0.000 description 16
- 239000000284 extract Substances 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 238000009877 rendering Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
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/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/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- 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/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- 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/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3221—Access to banking information through M-devices
-
- 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/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3223—Realising banking transactions through M-devices
-
- 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/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- 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/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- 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. 1A is a structural block diagram of a system for performing online shopping according to some related art.
- FIG. 1A illustrates the devices that are generally used in connection with the user using the electronic account to perform online shopping.
- a client terminal 101 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, and the payment server 103 can be a banking server or another server that has the authority to operate electronic accounts.
- FIG. 1B is a flowchart of a method for a user to complete a single online purchase according to some related art.
- a method for a user to complete a single online purchase is provided.
- 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, 0txw, Yeepay, 99bill, Baifubao, NetEase ePay, IPS, China PnR, or the like.
- a third party payment product such as Alipay, PayPal, Gopay, Tenpay, 0txw, 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 ).
- a corresponding payment server e.g., the payment server 103
- the merchant server 102 sends a payment request to payment server 103 .
- the payment request can include the Internet Protocol (IP) address and Uniform/Universal Resource Locator (URL) of the client terminal 101 .
- IP Internet Protocol
- URL Uniform/Universal Resource Locator
- 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.
- the payment page displayed by the client terminal 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.
- 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 method 150 has several deficiencies.
- 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. 1A is a structural block diagram of a system for performing online shopping according to some related art.
- FIG. 1B 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.
- 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 Personal Computer (PC), a laptop PC, a netbook PC, a Personal Digital Assistant (PDA), a Portable Multimedia Player (PMP), an mp3 player, a mobile device, a camera, a wearable device (e.g., a Head-Mounted Device (HMD), electronic clothes, electronic braces, an electronic necklace, an electronic accessory, an electronic tattoo, or a smart watch), or the like.
- 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.
- process 200 can be implemented by device 700 of FIG. 7 .
- process 200 can be implemented by device 800 of FIG. 8 .
- process 200 can be implemented by device 900 of FIG. 9 .
- process 200 can be implemented by device 1000 of FIG. 10 .
- process 200 can be implemented by system 1300 of FIG. 13 .
- 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 information, such as the upcoming payment sum information, from the two-dimensional code. 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 information. For example, 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 (e.g., 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 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.
- 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 e.g., the payment server 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.
- NFC Near Field Communication
- transaction information is obtained from the two-dimensional code.
- the second client terminal receives the two-dimensional code from the first client terminal. For example, in the event that the first client terminal displays the two-dimensional code, 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.
- a mobile communications network side e.g., the payment server
- 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.
- the upcoming payment sum 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.
- the upcoming payment 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.
- 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.
- process 400 can be implemented by device 700 of FIG. 7 .
- process 400 can be implemented by device 800 of FIG. 8 .
- process 400 can be implemented by device 900 of FIG. 9 .
- process 400 can be implemented by device 1000 of FIG. 10 .
- process 400 can be implemented by system 1300 of FIG. 13 .
- 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 information.
- 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.
- 410 - 440 of process 400 illustrated in FIG. 4 can be implemented by a payment server. In some embodiments, 410 - 440 of process 400 can be implemented by the same payment server. In some embodiments, 410 of process 400 can be implemented by a first payment server, and 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. In some embodiments, various other devices can implement any of 410 - 440 of process 400 . In some embodiments, 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.
- process 500 can be implemented by device 700 of FIG. 7 .
- process 500 can be implemented by device 800 of FIG. 8 .
- process 500 can be implemented by device 900 of FIG. 9 .
- process 500 can be implemented by device 1000 of FIG. 10 .
- process 500 can be implemented by system 1300 of FIG. 13 .
- 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 selects the product that the user 501 intends to buy
- the user can select to complete the electronic purchase of the product.
- 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 e.g., the first script code
- 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 “Alipay” in connection with executing the second script code.
- 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 .
- 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 application, or the like installed on the second client terminal 505 .
- 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 .
- the user 501 can select (e.g., click) 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 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. In the event that the payment server 504 does not provide an indication that the transaction is authorized to the first client terminal 502 , 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 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). For example, 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 .
- process 600 can be implemented by device 800 of FIG. 8 .
- process 600 can be implemented by device 900 of FIG. 9 .
- process 600 can be implemented by device 1000 of FIG. 10 .
- process 600 can be implemented by system 1300 of FIG. 13 .
- 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). 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 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.
- 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.
- the system 1300 implements the method 200 of FIG. 2 .
- the system 1300 implements the method 300 of FIG. 3 .
- the system 1300 implements the method 400 of FIG. 4 .
- the system 1300 implements the method 500 of FIG. 5 .
- the system 1300 implements the method 600 of FIG. 6 .
- the system 1300 implements the device 700 of FIG. 7 .
- the system 1300 implements the device 800 of FIG. 8 .
- the system 1300 implements the device 900 of FIG. 9 .
- the system 1300 implements the device 1000 of FIG. 10 .
- the system 1300 implements the device 1100 of FIG. 11 .
- the system 1300 implements the device 1200 of FIG. 12 .
- the system 1300 for processing an online transaction includes a first client terminal 1310 , a second client terminal 1320 , a merchant server 1330 , and a payment server 1340 .
- 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)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Cash Registers Or Receiving Machines (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Embodiments of the present application relate to a method, apparatus, and system for operating an electronic account or displaying a payment page. The method includes receiving, from a first client terminal, a payment platform display page acquisition request, providing, to the first client terminal, a payment platform display page, wherein the payment platform display page includes a first script code, wherein in the event that the first script code is executed, the first script code causes the first client terminal to obtain a payment page including a digital object unique identifier from a payment server and to display the payment page, wherein the digital object unique identifier indicates an upcoming payment sum, receiving verification information, and sending the verification information to the payment server to instruct the payment server to execute a deduction operation on an electronic account.
Description
- This application is a continuation of U.S. patent application Ser. No. 14/710,075, entitled METHOD, APPARATUS, AND SYSTEM FOR OPERATING AN ELECTRONIC ACCOUNT IN CONNECTION WITH AN ELECTRONIC TRANSACTION filed May 12, 2015 which is incorporated herein by reference for all purposes, which claims priority to People's Republic of China Patent Application No. 201410205929.8 entitled A METHOD FOR OPERATING ELECTRONIC ACCOUNTS AND A METHOD AND A DEVICE FOR DISPLAYING PAYMENT PAGES, filed May 15, 2014 which is incorporated herein by reference for all purposes.
- The present application relates to a field of computer technology. In particular, 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.
- A user can use an electronic account to perform online shopping.
FIG. 1A is a structural block diagram of a system for performing online shopping according to some related art. For example,FIG. 1A illustrates the devices that are generally used in connection with the user using the electronic account to perform online shopping. As illustrated inFIG. 1A , aclient terminal 101, amerchant server 102, and apayment server 103 can be used in connection with the user using the electronic account to perform online shopping. Theclient terminal 101 can be an electronic device such as a computer or a mobile phone. Themerchant server 102 can be a server affiliated (e.g., hosting) with a shopping website, and thepayment server 103 can be a banking server or another server that has the authority to operate electronic accounts. -
FIG. 1B is a flowchart of a method for a user to complete a single online purchase according to some related art. - Referring to
FIG. 1B , a method for a user to complete a single online purchase is provided. - At 111, the
client terminal 101 requests product information from themerchant server 102. - At 112, the
merchant server 102 pushes product page information to theclient terminal 101 so that a browser installed on theclient terminal 101 can display a page containing various pieces of product information. - At 113, 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 themerchant server 102. - The selected product information mentioned can be referred to as information on products that the user intends to buy.
- At 114, in order for the user to use an electronic account to pay for the products which the user intends to buy (e.g., the selected product information), the
merchant server 102 pushes a payment platform display page containing payment platform information to theclient terminal 101 so as to cause theclient terminal 101 to display a payment platform display page containing payment platform options. - According to some related art, 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, 0txw, Yeepay, 99bill, Baifubao, NetEase ePay, IPS, China PnR, or the like.
- At 115, the
client terminal 101 sends to themerchant server 102 payment platform information corresponding to the payment platform option selected by the user. - At 116, 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 theclient terminal 101 corresponds to thepayment server 103, then themerchant server 102 sends a payment request topayment server 103. - The payment request can include the Internet Protocol (IP) address and Uniform/Universal Resource Locator (URL) of the
client terminal 101. The URL includes information on the amount to be paid and the access address for the product information selected by the user. - At 117,
payment server 103 uses the aforesaid URL contained in the payment request as a basis for accessing themerchant server 103 and acquiring payment due information and user selected product information. Thepayment server 103 thereupon pushes, in accordance with the IP address of theclient terminal 101, a product page containing payment due information and user selected product information to theclient terminal 101 so as to instruct theclient terminal 101 to display this payment page. - According to some related art, the payment page displayed by the
client terminal 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. - At 118, the
client terminal 101 obtains the payment account number entered by the user in the payment account number input box, and theclient terminal 101 obtains the payment password in the payment password input box. Moreover, theclient terminal 101 sends both the payment account number and payment password that theclient terminal 101 obtained to thepayment server 103. - At 119, the
payment server 103 determines whether the payment account number and payment password sent by theclient 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 thepayment server 103 proceeds to 120. Otherwise, themethod 150 for a user to complete a single online purchase can be terminated. - At 120, the
payment server 103 looks up the electronic account matched with the payment account number sent by theclient terminal 101 and performs a deduction operation on the corresponding electronic account. Thepayment server 103 deducts the same amount as the payment due amount described above. - At 121, the
payment server 103 sends a notification of successful payment to themerchant server 102 to inform themerchant server 102 of the result of the current transaction. - At 122, the
merchant server 102 sends a notification of successful payment to theclient terminal 101, and themethod 150 for a user to complete a single online purchase ends. - Although one can successfully operate an electronic account using the procedure shown above in
FIG. 1B and thus use an electronic account to pay for a product, themethod 150 has several deficiencies. - First, the
payment server 103 needs to invoke a URL in order to cause theclient terminal 101 to display a payment page. The process of invoking a URL uses a relatively long period of processing time. As a result, theclient terminal 101 is required to wait for a relatively long time to complete the desired transaction. For example, 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. Second, themethod 150 requires that sensitive information (e.g., the payment password) from the user be transmitted to thepayment server 103 and thus runs the risk of leaking sensitive information. - Therefore, there is a need for a method, device, and system for processing an online transaction that is efficient and that does not risk exposure of sensitive information.
- Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
- The drawings described here are intended to further the understanding of the present application and form a part of this application. The illustrative embodiments of the present application and the descriptions thereof are intended to explain this application and do not constitute inappropriate limitation of the present application. Among the drawings:
-
FIG. 1A is a structural block diagram of a system for performing online shopping according to some related art. -
FIG. 1B 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. - 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. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, 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. As used herein, 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. According to various embodiments of the present disclosure, a terminal may include communication functionality. For example, a device may be a smart phone, a tablet, a mobile phone, a video phone, an e-book reader, a desktop Personal Computer (PC), a laptop PC, a netbook PC, a Personal Digital Assistant (PDA), a Portable Multimedia Player (PMP), an mp3 player, a mobile device, a camera, a wearable device (e.g., a Head-Mounted Device (HMD), electronic clothes, electronic braces, an electronic necklace, an electronic accessory, an electronic tattoo, or a smart watch), or the like.
- According to some embodiments of the present disclosure, 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 HomeSync™, Apple TV™, or Google TV™), a gaming console, an electronic dictionary, an electronic key, a camcorder, an electronic picture frame, or the like.
- According to various embodiments of the present disclosure, a device can be any combination of the foregoing devices. In addition, it will be apparent to one having ordinary skill in the art that a device according to various embodiments of the present disclosure is not limited to the foregoing devices.
- In some embodiments, 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. - Referring to
FIG. 2 , amethod 200 for operating an electronic account is provided. In some embodiments,process 200 can be implemented bydevice 700 ofFIG. 7 . In some embodiments,process 200 can be implemented bydevice 800 ofFIG. 8 . In some embodiments,process 200 can be implemented bydevice 900 ofFIG. 9 . In some embodiments,process 200 can be implemented bydevice 1000 ofFIG. 10 . In some embodiments,process 200 can be implemented bysystem 1300 ofFIG. 13 . - At 210, a payment platform display page acquisition request is received. In some embodiments, 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). For example, 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. For example, 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.
- At 220, a payment platform display page is provided. In some embodiments, the merchant server provides the payment platform display page. For example, 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. In response to receiving the payment platform display page acquisition request, 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.
- In some embodiments, 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. For example, 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). For example, 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. For example, 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.
- In some embodiments, 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. For example, the first client terminal executes the second script file code to send upcoming payment sum information to the payment server. In the event that 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. Thus, 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. For example, 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. In the event that 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.
- In some embodiments, the digital object unique identifier can, in addition to indicating the upcoming payment sum, indicate information of the product that is to be purchased. For example, 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.
- In some embodiments, 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.
- In some embodiments, 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” (DOUI) can be an identifier that uniquely identifies an electronic document. For example, 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. In some embodiments, 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. In some embodiments, 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. In some embodiments, the digital object unique identifier corresponds to two-dimensional codes, barcodes, or the like.
- In the event that a digital object unique identifier is a two-dimensional code, 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. In some embodiments, a second client terminal can scan, or otherwise receive, the two-dimensional code. For example, the second client can scan the two-dimensional code that is displayed by the first client terminal. In response to acquiring (e.g., scanning) the two-dimensional code from the first client terminal, the second client terminal can determine the upcoming payment sum information represented by the two-dimensional code.
- In some embodiments, 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 information, such as the upcoming payment sum information, from the two-dimensional code. 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 information. For example, the user can confirm that the transaction (e.g., the transaction corresponding to the two-dimensional code) is accurate or approved for payment.
- The second client terminal can send confirmation of the transaction to the payment server. For example, in the event that the second client terminal receives confirmation of the transaction from the user, the second client terminal can send confirmation of the transaction (e.g., the upcoming payment sum information) to the payment server.
- At 230, verification information is received. In some embodiments, the merchant server receives verification information. The payment server can send the verification information to the merchant server.
- In some embodiments, 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.
- In some embodiments, after a second client terminal confirms the upcoming payment sum information indicated by the digital object unique identifier displayed by the first client terminal, 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. In some embodiments, the electronic signature includes payment server identity information and the upcoming payment sum information. In some embodiments, 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.
- At 240, 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.
- In some embodiments, the payment server is registered with the merchant server (e.g., the payment server's identification information is stored at a secure location on the merchant server). In response to the merchant server receiving an electronic signature including at least payment server identity information and the upcoming payment sum information, 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. For example, 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.
- In some embodiments, 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. 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.
- In an example in which 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 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. In response to the mobile phone receiving from the mobile communications network side a message (e.g., a short message) that includes the verification code and that was issued (e.g., generated) in response to verification of the upcoming payment sum, the mobile phone number, and the bank card number, 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. In response to receiving the verification code from the user (e.g., the mobile device corresponding to the second client terminal), the mobile communications network (e.g., the payment server) determines that execution of the upcoming payment using the electronic account indicated by the bank card number has been authorized. Thus, the mobile communications network side pushes an authorization response message indicating successful authorization to the mobile device. In response to receiving the authorization response message, 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. - Referring to
FIG. 3 , amethod 300 for using a personal mobile financial service to authorize an electronic account to pay an upcoming payment amount is provided. In some embodiments,process 300 can be implemented bydevice 700 ofFIG. 7 . In some embodiments,process 300 can be implemented bydevice 800 ofFIG. 8 . In some embodiments,process 300 can be implemented bydevice 900 ofFIG. 9 . In some embodiments,process 300 can be implemented bydevice 1000 ofFIG. 10 . In some embodiments,process 300 can be implemented bysystem 1300 ofFIG. 13 . - At 305, a personal mobile financial service is activated. For example, 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.
- At 310, a purchase is initiated over a network. For example, a user can use a client terminal to purchase a product or service. In some embodiments, 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. For example, the user can click the “Use mobile phone wallet to pay” option provided by the electronic commerce website.
- At 315, a two-dimensional code acquisition request is communicated. In some embodiments, 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.
- At 320, a two-dimensional code is acquired. In some embodiments, 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). In some embodiments, 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. In the event that the payment server has generated, or otherwise acquired, the two-dimensional code 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.
- At 325, a two-dimensional code information is provided. In some embodiments, 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). In the event that the first client terminal receives the two-dimensional code information, the first client terminal can provide the two-dimensional code to the user (e.g., to the second client terminal). In some embodiments, 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. For example, 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.
- At 330, transaction information is obtained from the two-dimensional code. In some embodiments, the second client terminal receives the two-dimensional code from the first client terminal. For example, in the event that the first client terminal displays the two-dimensional code, the second client terminal can scan, or otherwise capture, the two-dimensional code displayed by the first client terminal. In some embodiments, transaction information (e.g., upcoming payment sum information) can be obtained from the two-dimensional code. For example, 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.
- At 335, a verification code acquisition request is communicated. In some embodiments, the second client terminal can send the verification code acquisition request to the mobile communications network. For example, the second client terminal can send the verification code acquisition request to the payment server. In some embodiments, 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.
- At 340, account information is verified. In some embodiments, a mobile 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.
- At 345, 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. 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). For example, 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.” In some embodiments, 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.
- At 350, an authorization response message is communicated to the payment server. In some embodiments, 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). In response to the payment server receiving the authorization response message from the second client terminal, the payment server can issue the verification information described in connection with 230 of
process 200 ofFIG. 2 . For example, the payment server can send the verification information to the merchant server. In some embodiments, the authorization response message communicated at 345 can be the same as the authorization response message communicated at 350. - Returning to 240 of
FIG. 2 , 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. - According to various embodiments of the present disclosure, 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.
- In some embodiments, the verification information includes electronic account information and upcoming payment sum information. In the event the payment server receives the verification 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.
- In some embodiments, 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. For example, 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.
- In some embodiments, 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.
- In the event that the payment server receives the verification information sent by the merchant server, 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.
- In the event that the payment server receives the verification information, 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.
- In some embodiments, 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.
- In some embodiments, 210-240 of
process 200 illustrated inFIG. 2 can be implemented by a merchant server. In some embodiments, 210-240 ofprocess 200 can be implemented by the same merchant server. In some embodiments, 210 and 220 ofprocess 200 can be implemented by a first merchant server, and 230 and 240 ofprocess 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 ofprocess 200. In some embodiments, the first client terminal and the second client terminal described in connection withprocess 200 andprocess 300 can be implemented by the same client terminal. - 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. - Referring to
FIG. 4 , amethod 400 for operating an electronic account is provided. In some embodiments,process 400 can be implemented bydevice 700 ofFIG. 7 . In some embodiments,process 400 can be implemented bydevice 800 ofFIG. 8 . In some embodiments,process 400 can be implemented bydevice 900 ofFIG. 9 . In some embodiments,process 400 can be implemented bydevice 1000 ofFIG. 10 . In some embodiments,process 400 can be implemented bysystem 1300 ofFIG. 13 . - At 410, a digital object unique identifier acquisition request is received. In some embodiments, 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. For example, 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.
- In some embodiments, 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. For example, in the event the first client terminal receives and displays a payment platform display page in connection with an online purchase, and the payment platform display page that is embedded therein, 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.
- In some embodiments, the first client terminal can send a code acquisition request to a payment server by executing the first script code. In the event that the payment server receives the code acquisition request from the first client terminal, the payment server can provide the first client terminal with a second script file code. In the event that 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. In the event that the first client terminal executes the second script file code, the first user terminal can send a digital object unique identifier acquisition request to the payment server. For example, the second script file code can cause the first client terminal to send a digital object unique identifier acquisition request to the payment server.
- At 420, a payment page including the digital object unique identifier is provided. In some embodiments, 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.
- In some embodiments, 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).
- At 430, verification information is provided. In some embodiments, the payment server provides the verification information to a merchant server. For example, 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.
- In some embodiments, the first client terminal can display the digital object unique identifier or information included therein to a user of the first client terminal. For example, 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. For example, 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 information. The second client terminal can provide an interface through which a user can confirm the upcoming payment sum. In the event that the second client terminal confirms the upcoming payment sum indicated by the digital object unique identifier displayed by the first user terminal, 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.
- At 440, 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.
- In some embodiments, the verification information includes electronic account information and upcoming payment sum information. The merchant server can send the verification information to the payment server. For example, 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.
- In some embodiments, the verification information includes a transaction serial number. The merchant server can send the verification information to the payment server. In the event that the payment server receives the verification information, the payment server can search for the electronic account information and the upcoming payment sum information corresponding to information included in the verification information. For example, 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.
- In some embodiments, 410-440 of
process 400 illustrated inFIG. 4 can be implemented by a payment server. In some embodiments, 410-440 ofprocess 400 can be implemented by the same payment server. In some embodiments, 410 ofprocess 400 can be implemented by a first payment server, and 420-440 ofprocess 400 can be implemented by a second payment server. The first payment server and the second payment server can be different payment servers. In some embodiments, various other devices can implement any of 410-440 ofprocess 400. In some embodiments, the first client terminal and the second client terminal described in connection withprocess 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. - Referring to
FIG. 5 , amethod 500 for operating an electronic account is provided. In some embodiments,process 500 can be implemented bydevice 700 ofFIG. 7 . In some embodiments,process 500 can be implemented bydevice 800 ofFIG. 8 . In some embodiments,process 500 can be implemented bydevice 900 ofFIG. 9 . In some embodiments,process 500 can be implemented bydevice 1000 ofFIG. 10 . In some embodiments,process 500 can be implemented bysystem 1300 ofFIG. 13 . - At 511, a
user 501 selects to complete an electronic purchase on a first client terminal 502 (e.g., a personal computer). Theuser 501 can select to complete the electronic purchase on a website in a browser installed on thefirst client terminal 502. Theuser 501 can select to complete the electronic purchase in an application installed on thefirst 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. In the event that theuser 501 selects the product that theuser 501 intends to buy, the user can select to complete the electronic purchase of the product. For example, theuser 501 can click a “Buy Now” in connection with the electronic purchase. In the event that theuser 501 selects to complete the electronic purchase, thefirst client terminal 502 can be instructed to open (e.g., navigate to) a payment platform display page. - At 512, a request for a payment platform display page is communicated. In some embodiments, the
first client terminal 502 sends a request for the payment platform display page to amerchant server 503. Thefirst client terminal 502 can request the payment platform display page from themerchant server 503 in response to theuser 501 selecting to complete the electronic purchase. Themerchant server 503 can be a server affiliated with an electronic commerce website (e.g., a website on which goods or services can be purchased). For example, themerchant server 503 can be a server that hosts an electronic commerce website, electronic commerce service, or the like. In some embodiments, the request is sent as an HTTP GET message directed to the URL of the payment platform display page. In some embodiments, 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. - At 513, a first script code is embedded in a payment platform display page. In some embodiments, 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. In some embodiments, themerchant 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. Themerchant server 503 can configure the first script code (e.g., the JS code) using transaction information. For example, themerchant 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. For example, JS code (e.g., the first script code) can be embedded in the payment platform display page data. In the event that the JS code is 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).
- In some embodiments, the first script code (e.g., the piece of JS code) includes a payment server address associated with a
payment server 504. In the event that the first script code is executed, thefirst 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. For example, the first script code can redirect the browser or application of thefirst 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. - At 514, a payment platform display page is communicated. In some embodiments, the
merchant server 503 communicates the payment platform display page to thefirst client terminal 502. In some embodiments, themerchant 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. - At 515, the payment platform display page is displayed. In some embodiments, 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 offirst 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. - At 516, a request for a payment page module is communicated. For example, the
first client terminal 502 can send a payment page module acquisition request to apayment server 504 indicated by the payment server address included in the first script code. Thefirst client terminal 502 can send the payment page module acquisition request to thepayment server 504 in response to thefirst client terminal 502 executing the first script code. - In some embodiments, 515 and 516 of
process 500 are executed asynchronously. - At 517, a second script code is generated. In some embodiments, the
payment server 504 generates the second script code. For example, thepayment 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. - In some embodiments, the second script code generated by the
payment server 504 implements the payment page module functions. - At 518, the second script code is communicated. In some embodiments, the
payment server 504 sends the second script code to thefirst client terminal 502. - At 519, a payment platform option can be rendered. In some embodiments, the second script code causes the payment platform option to be rendered. For example, in the event that the
first client terminal 502 executes the second script code, thefirst 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). - For example, if the name of the payment platform corresponding to the
payment server 504 is “Alipay,” thefirst client terminal 502 can render the payment platform option “Alipay” in connection with executing the second script code. - At 520, the payment platform display page is displayed. In some embodiments, the requested payment platform display page is displayed by the
first client terminal 502. For example, thefirst client terminal 502 can display the payment platform display page including the payment platform options. - At 521, a payment platform option is selected. In some embodiments, the payment platform option is selected by the
user 501. Theuser 501 can input the selection to thefirst client terminal 502. For example, theuser 501 can click a payment platform option displayed on the payment platform display page. - At 522, a request for generation of a two-dimensional code is communicated. In some embodiments, 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, thefirst client terminal 502 sends a two-dimensional code generation request to thepayment server 504 corresponding to the payment platform option selected (e.g., clicked) by theuser 501. - In some embodiments, the two-dimensional code generation request includes upcoming payment sum information and information on the product to be purchased.
- At 523, two-dimensional code information is generated. In some embodiments, in the event that the
payment server 504 receives the two-dimensional code information, thepayment server 504 generates the two-dimensional code information. Thepayment 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. - In some embodiments, 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. For example, 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.
- At 524, a two-dimensional code information address is communicated. In some embodiments, the
payment server 504 sends the two-dimensional code information address to thefirst 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. Thepayment server 504 can send the generated two-dimensional code information address (e.g., URL) to thefirst client terminal 502 in response to thepayment server 504 receiving the two-dimensional code generation request. - At 525, the two dimensional code information is acquired. In some embodiments, the two-dimensional code information is acquired (e.g., downloaded) from the two-dimensional code information address. For example, the
first client terminal 502 can download the two-dimensional code information from the two-dimensional code information address. Theclient terminal 502 can download the two-dimensional code information from thepayment server 504 according to the two-dimensional code information URL in connection with executing the second script code. For example, the second script code can cause thefirst client terminal 502 to automatically download the two-dimensional code information. - At 526, a two-dimensional code is displayed. In some embodiments, the
first client terminal 502 displays the two-dimensional code. Thefirst 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. - At 527, the two-dimensional code is acquired. In some embodiments, the
user 501 acquires the two-dimensional code from thefirst client terminal 502. For example, theuser 501 can use a second client terminal 505 (e.g., a mobile phone) to scan the two-dimensional code displayed by thefirst client terminal 502. Thesecond client terminal 505 can scan the two-dimensional code using an image capture function (e.g., a camera function of the mobile device). In some embodiments, theuser 501 can manually input information included in the two-dimensional code to thesecond client terminal 505. In some embodiments, 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. Thesecond 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, thesecond client terminal 505 can obtain the upcoming payment sum information, the information on the product to be purchased, and information for rendering a “Checkout.” - At 528, information associated with completing an electronic purchase is rendered. In some embodiments, the
second client terminal 505 renders a page associated with completing an electronic purchase. For example, thesecond 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 theuser 501 can confirm payment in connection with the purchase of the product to be purchased. The page can be displayed in a browser, an application, or the like installed on thesecond client terminal 505. - At 529, the payment in connection with the purchase of the product to be purchased is confirmed. In some embodiments, the
user 501 can input confirmation of the payment through the page displayed on thesecond client terminal 505. After confirming that the upcoming payment sum and the information on the product to be purchased are free of error, theuser 501 can select (e.g., click) the “Confirm Payment” option. In the event that theuser 501 confirms the payment (e.g., theuser 501 selects the “Confirm Payment” option), thesecond 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 verification code request can include the upcoming payment sum, the phone number of thesecond client terminal 505, and a bank card number associated with the phone number. In the event that 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 thesecond client terminal 505. Theuser 501 can input the verification code into thesecond client terminal 505. The mobile communication network side (e.g., the payment server 504) can push the verification code to thesecond client terminal 502 via a Short Message Service (SMS) message. In response to receiving the SMS (on the second client terminal 502), the user can input the verification code into thesecond client terminal 502. In the event that theuser 501 inputs the verification code into thesecond client terminal 505, thesecond client terminal 505 can send the verification code to the mobile communications network side. In response to receiving the verification code, the mobile communications side can send an authorization response message to thesecond client terminal 505. The authorization response message can indicate that the authorization was successful. - At 530, an authorization notification is communicated. In some embodiments, the
second client terminal 505 sends the authorization notification to thepayment server 504. The authorization notification can include information associated with the authorized electronic account. For example, the authorization notification can include the electronic account information indicated by the bank card number. - At 531, the
payment server 503 is queried as to whether the transaction is authorized. In some embodiments, thefirst client terminal 502 can query thepayment server 504 as to whether the upcoming payment sum has been authorized for payment. In some embodiments, theuser 501 can manually control thefirst client terminal 502 to query thepayment server 504. Thefirst client terminal 502 can automatically query thepayment server 504 at predetermined intervals. For example, by executing the second script code, thefirst client terminal 502 can periodically query thepayment server 504 on whether the upcoming payment sum has been authorized for payment. - In some embodiments, 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. - In some embodiments, 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, thefirst client terminal 502 can send a query request including the transaction serial number to thepayment server 504 to trigger thepayment server 504 to determine whether an authorization notification including the transaction serial number has been received. In the event that thepayment server 504 determines that the authorization notification including the transaction serial number has been received, thenpayment server 504 can send an indication that the transaction is authorized to thefirst client terminal 502. Accordingly, thefirst client terminal 502 can determine that the upcoming payment sum has been authorized for payment. In the event that thepayment server 504 does not provide an indication that the transaction is authorized to thefirst client terminal 502, thefirst client terminal 502 determines that the upcoming payment sum has not been authorized for payment. - At 532, a payment token is communicated. In some embodiments, the
payment server 504 sends the payment token to thefirst client terminal 502. In the event that thepayment server 504 confirms that the upcoming payment sum has been authorized for payment, thepayment server 504 can send a payment token to thefirst client terminal 502. - In some embodiments, the payment token is a unique token (e.g., an alphanumeric string). For example, the payment token can be one kind of the verification information. In some embodiments, the payment token includes an electronic signature and transaction serial number from the
payment server 504. The payment token can be generated by thepayment server 504. The payment token can include an electronic signature of thepayment server 504. - In some embodiments, 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. - At 533, the payment token is communicated to the
merchant server 503. Thefirst client terminal 502 can send the payment token to themerchant server 503. - At 534, the payment token is communicated to the
payment server 504. Themerchant server 503 can send the payment token to thepayment server 504 in connection with receiving payment for the electronic purchase. For example, themerchant server 503 can exchange the payment token for payment with thepayment server 504. - For example, in the event that a funds request time point has arrived (e.g., it is time for payment in connection with the electronic purchase) determined according to a funds request cycle, the
merchant server 503 sends the payment token to thepayment server 504. - At 535, a deduction operation on the authorized electronic account is executed. In some embodiments, in the event that the
payment server 504 receives the payment token (e.g., from the merchant server 503), thepayment server 504 executes a deduction operation on the authorized electronic account saved in correspondence with the transaction serial number in the payment token. Thepayment server 504 can perform a verification process to verify the payment token (e.g., to verify the authenticity of the payment token). For example, thepayment server 504 can verify the payment server signature in the payment token. Thepayment server 504 can determine whether the signature from a payment server that is included in the payment token matches the signature of thepayment server 504. In the event that thepayment server 504 verifies the payment token, thepayment 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. - At 536, a status notification of the funds deduction is communicated. In some embodiments, 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. Thepayment server 504 can send the notification of the successful funds deduction to themerchant server 503. - At 537, a status notification of a payment is communicated. In some embodiments, the
merchant server 503 instructs thefirst client terminal 502 to display a notification of successful or failed payment. The notification of successful or failed payment can be communicated to thefirst client terminal 502. In the event that thefirst client terminal 502 receives the notification of the successful or failed payment, thefirst client terminal 502 can display a notification that the payment was successful or unsuccessful to theuser 501. For example, thefirst client terminal 502 can provide an alert to theuser 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. - In some embodiments, the
merchant server 503 communicates the status notification of payment to thesecond client terminal 505. The notification of payment can be concurrently communicated to thefirst client terminal 502 and thesecond client terminal 505. In the event that thesecond client terminal 505 receives the notification of the payment, thesecond client terminal 505 can display a notification that the payment was successful or unsuccessful to theuser 501. For example, thesecond client terminal 505 can provide an alert to theuser 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. - Referring to
FIG. 6 , amethod 600 for displaying a payment page is provided. In some embodiments,process 600 can be implemented bydevice 700 ofFIG. 7 . In some embodiments,process 600 can be implemented bydevice 800 ofFIG. 8 . In some embodiments,process 600 can be implemented bydevice 900 ofFIG. 9 . In some embodiments,process 600 can be implemented bydevice 1000 ofFIG. 10 . In some embodiments,process 600 can be implemented bysystem 1300 ofFIG. 13 . - At 610, a payment platform display page acquisition request is communicated. In some embodiments, the first client terminal sends the payment platform display page acquisition request to a merchant server.
- At 620, a payment platform display page is obtained. In some embodiments, the first client terminal can obtain the payment platform display page. For example, the first client terminal can receive the payment platform display page from the merchant server. In some embodiments, 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). For example, the first script code can redirect the first client terminal to the payment server. At 630, the first script code is executed. In some embodiments, the first client terminal executes the first script code. For example, in response to receiving the payment platform display page, the first client terminal 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. In the event that the first client terminal displays the payment platform display page, 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. In the event that the first client terminal 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.
- In some embodiments, the first script code includes a storage address of a second script file code in a payment server. In the event that the first script code includes the storage address of the second script file code in the 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.
- In the event that the first client terminal receives the second script code, 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.
- In some embodiments, 610-630 of
process 600 illustrated inFIG. 6 can be implemented by a client terminal. In some embodiments, 610-630 ofprocess 600 can be implemented by the same client terminal. In some embodiments, 610 ofprocess 600 can be implemented by a first client terminal, and 620 and 630 ofprocess 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 ofprocess 600. -
FIG. 7 is a structural diagram of a device for operating an electronic account according to various embodiments of the present disclosure. - Referring to
FIG. 7 , adevice 700 configured to operate an electronic account is provided. In some embodiments,device 700 is used to implement at least a part ofmethod 200 ofFIG. 2 . In some embodiments,device 700 is used to implement at least a part ofmethod 300 ofFIG. 3 . In some embodiments,device 700 is used to implement at least a part ofmethod 400 ofFIG. 4 . In some embodiments,device 700 is used to implement at least a part ofmethod 500 ofFIG. 5 . In some embodiments,device 700 can be implemented bysystem 1300 ofFIG. 13 . In some embodiments, thedevice 700 is implemented in a merchant server. - As illustrated in
FIG. 7 , thedevice 700 includes arequest receiving module 710, a pageinformation sending module 720, aninformation receiving module 730, and a verificationinformation sending module 740. - In some embodiments, the
request receiving module 710 is configured to receive a payment platform display page acquisition request. Therequest receiving module 710 can receive the payment platform display page acquisition request from a first client terminal. - In some embodiments, the page
information sending module 720 is configured to provide a payment platform display page in which is embedded a first script code. For example, in the event that therequest receiving module 710 receives the payment platform display page acquisition request, 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). 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. - In some embodiments, the
information receiving module 730 is configured to receive verification information. The payment server can issue the verification information. In some embodiments, 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. - In some embodiments, the verification
information sending module 740 is configured to communicate the verification information. For example, the verificationinformation sending module 740 can send the verification information to the payment server. The verificationinformation sending module 740 can send the verification information received by theinformation 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. - Referring to
FIG. 8 , adevice 800 configured to operate an electronic account is provided. In some embodiments,device 800 is used to implement at least a part ofmethod 200 ofFIG. 2 . In some embodiments,device 800 is used to implement at least a part ofmethod 300 ofFIG. 3 . In some embodiments,device 800 is used to implement at least a part ofmethod 400 ofFIG. 4 . In some embodiments,device 800 is used to implement at least a part ofmethod 500 ofFIG. 5 . In some embodiments,device 800 can be implemented bysystem 1300 ofFIG. 13 . In some embodiments, thedevice 800 is implemented in a merchant server. - As illustrated in
FIG. 8 ,device 800 includes asignal receiver 810, aprocessor 820, and asignal transmitter 830. - In some embodiments, 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. In some embodiments, 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. - In some embodiments, the
processor 820 is configured to control thesignal transmitter 830 to provide the first client terminal with a payment platform display page in which is embedded a first script code. For example, in the event that thesignal receiver 810 receives a payment platform display page authorization request, theprocessor 820 can control thesignal 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. - In some embodiments, the
signal transmitter 830 is configured to provide, under the control of theprocessor 820, the first client terminal with a payment platform display page in which a first script code is embedded. In some embodiments, thesignal transmitter 830 is configured to send the verification information received by thesignal 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. - Referring to
FIG. 9 , adevice 900 configured to operate an electronic account is provided. In some embodiments,device 900 is used to implement at least a part ofmethod 200 ofFIG. 2 . In some embodiments,device 900 is used to implement at least a part ofmethod 300 ofFIG. 3 . In some embodiments,device 900 is used to implement at least a part ofmethod 400 ofFIG. 4 . In some embodiments,device 900 is used to implement at least a part ofmethod 500 ofFIG. 5 . In some embodiments,device 900 can be implemented bysystem 1300 ofFIG. 13 . In some embodiments, thedevice 900 is implemented in a payment server. - As illustrated in
FIG. 9 , thedevice 900 includes arequest receiving module 910, apage providing module 920, amessage receiving module 930, aninformation sending module 940, aninformation receiving module 950, and anoperation executing module 960. - In some embodiments, 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. - In some embodiments, the
page providing module 920 is configured to provide a payment page including a digital object unique identifier to the first client terminal. For example, thepage providing module 920 can send the payment page to the first client terminal in the event that therequest receiving module 910 has received the digital object unique identifier acquisition request. - In some embodiments, 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 themessage 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 themessage receiving module 930. - In some embodiments, the
information sending module 940 is configured to send verification information to a merchant server. For example, theinformation sending module 940 can send the verification information to the merchant server in the event that themessage receiving module 930 receives the authorization notification. - In some embodiments, the
information receiving module 950 is configured to receive the verification information sent by the merchant server. - In some embodiments, the
operation executing module 960 is configured to execute a deduction operation on the electronic account. For example, theoperation executing module 960 can execute the deduction operation on the electronic account in the event that theinformation 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. - Referring to
FIG. 10 , adevice 1000 configured to operate an electronic account is provided. In some embodiments,device 1000 is used to implement at least a part ofmethod 200 ofFIG. 2 . In some embodiments,device 1000 is used to implement at least a part ofmethod 300 ofFIG. 3 . In some embodiments,device 1000 is used to implement at least a part ofmethod 400 ofFIG. 4 . In some embodiments,device 1000 is used to implement at least a part ofmethod 500 ofFIG. 5 . In some embodiments,device 1000 can be implemented bysystem 1300 ofFIG. 13 . In some embodiments, thedevice 1000 is implemented in a payment server. - As illustrated in
FIG. 10 , thedevice 1000 includes asignal receiver 1010, asignal transmitter 1020, and aprocessor 1030. - In some embodiments, 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. - In some embodiments, the
signal transmitter 1020 is configured to provide a payment page including a digital object unique identifier to the first client terminal. For example, the signal transmitter can send the digital object unique identifier in the event that thesignal receiver 1010 has received the digital object unique identifier acquisition request. In the event that thesignal receiver 1010 receives the authorization notification, thesignal receiver 1010 can send the verification information to the merchant server. - In the event that the
signal receiver 1010 receives verification information sent by the merchant server, a deduction operation is executed on the electronic account. In some embodiments, theprocessor 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. - Referring to
FIG. 11 , adevice 1100 configured to display a payment page is provided. In some embodiments,device 1100 is used to implement at least a part ofmethod 200 ofFIG. 2 . In some embodiments,device 1100 is used to implement at least a part ofmethod 300 ofFIG. 3 . In some embodiments,device 1100 is used to implement at least a part ofmethod 400 ofFIG. 4 . In some embodiments,device 1100 is used to implement at least a part ofmethod 500 ofFIG. 5 . In some embodiments,device 1100 can be implemented bysystem 1300 ofFIG. 13 . In some embodiments, thedevice 1100 is implemented in a client terminal. - As illustrated in
FIG. 11 , thedevice 1100 includes asending module 1110, aninformation obtaining module 1120, and a paymentpage displaying module 1130. - In some embodiments, the sending
module 1110 is configured to send a payment platform display page acquisition request to a merchant server. - In some embodiments, 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. For example, theinformation obtaining module 1120 can obtain the payment platform display page in the event that therequest 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). For example, the first script code can redirect the client terminal to the payment server. - In some embodiments, the payment
page displaying module 1130 is configured to execute the first script code embedded in the payment platform display page obtained by theinformation obtaining module 1120 and thereby acquire a payment page containing a digital object unique identifier from a payment server and display the payment page. - In the event that the payment page is displayed, the upcoming payment sum indicated by the digital object unique identifier can be confirmed. In response to confirming the upcoming payment sum indicated by the digital object unique identifier that is displayed, 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. For example, 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. - Referring to
FIG. 12 , adevice 1200 configured to display a payment page is provided. In some embodiments,device 1200 is used to implement at least a part ofmethod 200 ofFIG. 2 . In some embodiments,device 1200 is used to implement at least a part ofmethod 300 ofFIG. 3 . In some embodiments,device 1200 is used to implement at least a part ofmethod 400 ofFIG. 4 . In some embodiments,device 1200 is used to implement at least a part ofmethod 500 ofFIG. 5 . In some embodiments,device 1200 can be implemented bysystem 1300 ofFIG. 13 . In some embodiments, thedevice 1200 is implemented in a client terminal. - As illustrated in
FIG. 12 , thedevice 1200 includes asignal transmitter 1210, aninformation collector 1220, aprocessor 1230, and aninformation display device 1240. - In some embodiments, the
signal transmitter 1210 is configured to send a payment platform display page acquisition request to a merchant server. - In some embodiments, 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). For example, the first script code can redirect the client terminal to the payment server. Theinformation collector 1220 can obtain the payment platform display page in the event that thesignal transmitter 1210 has sent a payment platform display page acquisition request. In some embodiments, the information collector is configured to acquire, under the control of theprocessor 1230, a payment page including a digital object unique identifier from a payment server. - In some embodiments, the
processor 1230 is configured to execute the first script code and thereby control theinformation collector 1220 to acquire the payment page including the digital object unique identifier from the payment server. - In some embodiments, the
information display device 1240 is configured to display the payment page including the digital object unique identifier acquired by theinformation collector 1220. - In the event that the payment page is displayed, 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. - Referring to
FIG. 13 , asystem 1300 for processing an online transaction is provided. In some embodiments, thesystem 1300 implements themethod 200 ofFIG. 2 . In some embodiments, thesystem 1300 implements themethod 300 ofFIG. 3 . In some embodiments, thesystem 1300 implements themethod 400 ofFIG. 4 . In some embodiments, thesystem 1300 implements themethod 500 ofFIG. 5 . In some embodiments, thesystem 1300 implements themethod 600 ofFIG. 6 . In some embodiments, thesystem 1300 implements thedevice 700 ofFIG. 7 . In some embodiments, thesystem 1300 implements thedevice 800 ofFIG. 8 . In some embodiments, thesystem 1300 implements thedevice 900 ofFIG. 9 . In some embodiments, thesystem 1300 implements thedevice 1000 ofFIG. 10 . In some embodiments, thesystem 1300 implements thedevice 1100 ofFIG. 11 . In some embodiments, thesystem 1300 implements thedevice 1200 ofFIG. 12 . - The
system 1300 for processing an online transaction includes afirst client terminal 1310, asecond client terminal 1320, amerchant server 1330, and apayment server 1340. Thesystem 1300 can include anetwork 1350 over which thefirst client terminal 1310, thesecond client terminal 1320, themerchant server 1330, and thepayment server 1340 can communicate. Thenetwork 1350 can be a LAN, a Wide Area Network (WAN), the Internet, or the like. In some embodiments, the various devices of the system 1300 (e.g.,devices -
FIG. 14 is a functional diagram of a computer system for processing an online transaction according to various embodiments of the present disclosure. - Referring to
FIG. 14 , acomputer system 1400 for processing an online transaction is provided. As will be apparent, other computer system architectures and configurations can be used to implement processing of online transactions.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. For example,processor 1402 can be implemented by a single-chip processor or by multiple processors. In some embodiments,processor 1402 is a general purpose digital processor that controls the operation of thecomputer system 1400. Using instructions retrieved frommemory 1410, theprocessor 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 withmemory 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). As is well known in the art, 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 onprocessor 1402. Also as is well known in the art, primary storage typically includes basic operating instructions, program code, data, and objects used by theprocessor 1402 to perform its functions (e.g., programmed instructions). For example,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. For example,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 thecomputer system 1400, and is coupled either bi-directionally (read/write) or uni-directionally (read only) toprocessor 1402. For example,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 fixedmass storage 1420 can also, for example, provide additional data storage capacity. The most common example ofmass storage 1420 is a hard disk drive.Mass storage device 1412 and fixedmass storage 1420 generally store additional programming instructions, data, and the like that typically are not in active use by theprocessor 1402. It will be appreciated that the information retained withinmass storage device 1412 and fixedmass storage 1420 can be incorporated, if needed, in standard fashion as part of memory 1410 (e.g., RAM) as virtual memory. - In addition to providing
processor 1402 access to storage subsystems,bus 1414 can also be used to provide access to other subsystems and devices. As shown, these can include adisplay monitor 1418, anetwork interface 1416, akeyboard 1404, and apointing device 1406, as well as an auxiliary input/output device interface, a sound card, speakers, and other subsystems as needed. For example, thepointing 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 allowsprocessor 1402 to be coupled to another computer, computer network, or telecommunications network using a network connection as shown. For example, through thenetwork interface 1416, theprocessor 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 thecomputer system 1400 to an external network and transfer data according to standard protocols. For example, various process embodiments disclosed herein can be executed onprocessor 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 (not shown) can also be connected toprocessor 1402 throughnetwork interface 1416. - An 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 theprocessor 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. In addition,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. - The above-stated are merely embodiments of the present application and do not limit the present application. For persons skilled in the art, the present application may have various modifications and variations. Any modification, equivalent substitution, or improvement made in keeping with the spirit and principles of the present application shall be included within the scope of the claims of the present application.
- Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
Claims (20)
1. A method, comprising:
receiving, by one or more merchant servers, a payment platform display page acquisition request from a first client terminal via one or more networks;
providing, by the one or more merchant servers, a payment platform display page to the first client terminal, wherein:
in connection with the first client terminal executing the payment platform display page, one or more script codes are obtained by the first client terminal;
the first client terminal obtains a digital object unique identifier from a payment server and the first client terminal is caused to display a payment page in response to executing at least one of the one or more script codes;
the digital object unique identifier indicates an upcoming payment sum; and
the digital object unique identifier is based at least in part on information pertaining to the upcoming payment sum that is provided to the payment server by the first client terminal;
receiving, by the one or more merchant servers, verification information in connection with an authorization for the online transaction being communicated by a second client terminal, wherein:
the second client terminal obtains the verification information based at least in part on obtaining the digital object unique identifier from the first client terminal; and
in response to receiving the verification information, sending, by the one or more merchant servers, the verification information to the payment server to instruct the payment server to perform a payment with respect to a corresponding transaction.
2. The method of claim 1 , wherein the digital object unique identifier is generated in response to information pertaining to the upcoming payment sum being provided to the payment server by the first client terminal.
3. The method of claim 1 , wherein the verification information includes a payment sum, information pertaining to the payment server identity, and an identifier corresponding to the online transaction.
4. The method of claim 1 , further comprising:
issuing the verification information, wherein issuing the verification information comprises:
causing to be displayed, by the first client terminal, the digital object unique identifier;
receiving, from the second client terminal, a confirmation of the upcoming payment sum indicated by the digital object unique identifier; and
sending an indication of the confirmation of the upcoming payment sum to the payment server, the indication of the confirmation of the upcoming payment sum corresponding to the authorization for the transaction communicated by the second client terminal.
5. The method of claim 4 , wherein the confirmation of the upcoming payment sum indicated by the digital object unique identifier is obtained using a personal mobile financial service provided to a user to authorize the electronic account to pay the upcoming payment sum.
6. The method of claim 1 , wherein:
the one or more script codes obtained by the first client terminal comprises a first script code and a second script code;
the first script code is obtained in connection with receiving the payment platform display page;
the second script code is obtained from a payment server in response to the first script being executed;
the first script code includes a storage address of the second script code in the payment server; and
in response to the second script code being executed, the second script code causes the first client terminal to:
send upcoming payment sum information to the payment server; and
in response to obtaining the payment page from the payment server, display the payment page.
7. The method of claim 1 , wherein:
the verification information includes electronic account information and upcoming payment sum information; and
the sending the verification information to the payment server to instruct the payment server to perform the payment with respect to the corresponding transaction comprises:
sending 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.
8. The method of claim 1 , wherein:
the verification information includes a transaction serial number;
the sending the verification information to the payment server to instruct the payment server to perform the payment with respect to the corresponding transaction comprises:
sending the verification information to the payment server;
the payment server uses a mapping relationship between the transaction serial number, electronic account information, and upcoming payment sum information to look up the electronic account information and the upcoming payment sum information mapped to the transaction serial number included in the verification information; and
the payment server executes a deduction operation on the electronic account according to the electronic account information and the upcoming payment sum information mapped to the transaction serial number.
9. The method of claim 1 , wherein:
the one or more script codes obtained by the first client terminal comprises a first script code and a second script code;
the first script code is obtained in connection with receiving the payment platform display page; and
the first script code includes a storage address of a second script code in the payment server.
10. The method of claim 1 , wherein:
the one or more script codes obtained by the first client terminal comprises a first script code and a second script code;
the first script code is obtained in connection with receiving the payment platform display page;
the first script code redirects the first client terminal to the payment server in response to the first script code being executed; and
the second script code is obtained by the first client terminal from the payment server.
11. The method of claim 1 , wherein:
the one or more script codes obtained by the first client terminal comprises a first script code and a second script code;
the first script code is JavaScript embedded in the payment platform display page;
the first script code is obtained in connection with receiving the payment platform display page; and
the first script code causes the first client terminal to be redirected to the payment server in response to the first script code being executed.
12. The method of claim 1 , wherein the verification information corresponds to an electronic signature comprising at least payment server identity information and information pertaining to the upcoming payment sum information.
13. The method of claim 1 , wherein the verification information is received in connection with the second client terminal executing a personal mobile financial service application to authorize the payment with respect to the corresponding transaction.
14. A device, comprising:
at least one processor associated with a merchant server, the at least one processors configured to:
receive, from a first client terminal via one or more networks, a payment platform display page acquisition request;
provide, to the first client terminal, a payment platform display page, wherein:
in connection with the first client terminal executing the payment platform display page, one or more script codes are obtained by the first client terminal;
the first client terminal obtains a digital object unique identifier from a payment server and the first client terminal is caused to display a payment page in response to executing at least one of the one or more script codes;
the digital object unique identifier indicates an upcoming payment sum; and
the digital object unique identifier is based at least in part on information pertaining to the upcoming payment sum that is provided to the payment server by the first client terminal;
receive verification information in connection with an authorization for the online transaction being communicated by a second client terminal, wherein:
the second client terminal obtains the verification information based at least in part on obtaining the digital object unique identifier from the first client terminal; and
in response to receiving the verification information, send the verification information to the payment server to instruct the payment server to perform a payment with respect to a corresponding transaction, the verification information being sent to the payment server via one or more networks; and
a memory coupled to the at least one processor and configured to provide the at least one processor with instructions.
15. The device of claim 14 , wherein the at least one processor is further configured to:
issue the verification information, wherein issuing the verification information comprises:
causing to be displayed, by the first client terminal, the digital object unique identifier;
receiving, from the second client terminal, a confirmation of the upcoming payment sum indicated by the digital object unique identifier; and
sending an indication of the confirmation of the upcoming payment sum to the payment server, the indication of the confirmation of the upcoming payment sum corresponding to the authorization for the transaction communicated by the second client terminal.
16. The device of claim 15 , wherein the confirmation of the upcoming payment sum indicated by the digital object unique identifier is obtained using a personal mobile financial service provided to a user to authorize the electronic account to pay the upcoming payment sum.
17. A computer program product, the computer program product being embodied in a non-transitory computer readable storage medium and comprising computer instructions for:
receiving, by one or more merchant servers, a payment platform display page acquisition request from a first client terminal via one or more networks;
providing, by the one or more merchant servers, a payment platform display page to the first client terminal, wherein:
in connection with the first client terminal executing the payment platform display page, one or more script codes are obtained by the first client terminal;
the first client terminal obtains a digital object unique identifier from a payment server and the first client terminal is caused to display a payment page in response to executing at least one of the one or more script codes;
the digital object unique identifier indicates an upcoming payment sum;
the digital object unique identifier is based at least in part on information pertaining to the upcoming payment sum that is provided to the payment server by the first client terminal;
receiving, by the one or more merchant servers, verification information in connection with an authorization for the online transaction being communicated by a second client terminal, wherein:
the second client terminal obtains the verification information based at least in part on obtaining the digital object unique identifier from the first client terminal; and
in response to receiving the verification information, sending, by the one or more merchant servers, the verification information to the payment server to instruct the payment server to perform a payment with respect to a corresponding transaction.
18. The computer program product of claim 17 , further comprising instructions for:
issuing the verification information, wherein instructions for issuing the verification information comprise instructions for:
causing to be displayed, by the first client terminal, the digital object unique identifier;
receiving, from the second client terminal, a confirmation of the upcoming payment sum indicated by the digital object unique identifier; and
sending an indication of the confirmation of the upcoming payment sum to the payment server, the indication of the confirmation of the upcoming payment sum corresponding to the authorization for the transaction communicated by the second client terminal.
19. The computer program product of claim 18 , wherein the confirmation of the upcoming payment sum indicated by the digital object unique identifier is obtained using a personal mobile financial service provided to a user to authorize the electronic account to pay the upcoming payment sum.
20. The computer program product of claim 17 , wherein:
the one or more script codes obtained by the first client terminal comprises a first script code and a second script code;
the first script code is obtained in connection with receiving the payment platform display page;
the second script code is obtained from a payment server in response to the first script being executed;
the first script code includes a storage address of a second script code in the payment server; and
in response to the second script code being executed, the second script code causes the first client terminal to:
send upcoming payment sum information to the payment server; and
in response to obtaining the payment page from the payment server, display the payment page.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/951,901 US20210073761A1 (en) | 2014-05-15 | 2020-11-18 | Method, apparatus, and system for operating an electronic account in connection with an electronic transaction |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410205929.8 | 2014-05-15 | ||
CN201410205929.8A CN105099688B (en) | 2014-05-15 | 2014-05-15 | A kind of operating method of electronic account, the methods of exhibiting and device for paying the page |
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 |
US16/951,901 US20210073761A1 (en) | 2014-05-15 | 2020-11-18 | Method, apparatus, and system for operating an electronic account in connection with an electronic transaction |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/710,075 Continuation US10902393B2 (en) | 2014-05-15 | 2015-05-12 | Method, apparatus, and system for operating an electronic account in connection with an electronic transaction |
Publications (1)
Publication Number | Publication Date |
---|---|
US20210073761A1 true US20210073761A1 (en) | 2021-03-11 |
Family
ID=54538831
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/710,075 Active 2036-08-01 US10902393B2 (en) | 2014-05-15 | 2015-05-12 | Method, apparatus, and system for operating an electronic account in connection with an electronic transaction |
US16/951,901 Pending US20210073761A1 (en) | 2014-05-15 | 2020-11-18 | Method, apparatus, and system for operating an electronic account in connection with an electronic transaction |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/710,075 Active 2036-08-01 US10902393B2 (en) | 2014-05-15 | 2015-05-12 | Method, apparatus, and system for operating an electronic account in connection with an electronic transaction |
Country Status (7)
Country | Link |
---|---|
US (2) | US10902393B2 (en) |
EP (1) | EP3143571A1 (en) |
JP (1) | JP6509253B2 (en) |
KR (2) | KR102218168B1 (en) |
CN (2) | CN105099688B (en) |
HK (1) | HK1213392A1 (en) |
TW (1) | TWI665619B (en) |
Families Citing this family (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102096146B1 (en) | 2014-09-02 | 2020-04-28 | 애플 인크. | Semantic framework for variable haptic output |
CA2965668C (en) * | 2014-10-23 | 2023-07-11 | Capital One Services, Llc | Financial status display |
CN105631669A (en) * | 2015-12-24 | 2016-06-01 | 中国建设银行股份有限公司 | Method and device which verifies payment data |
CN106934615B (en) * | 2015-12-29 | 2020-08-04 | 阿里巴巴集团控股有限公司 | Payment and service processing method and device based on mobile terminal bar code |
CN106934607A (en) * | 2015-12-31 | 2017-07-07 | 华为技术有限公司 | A kind of method of payment, payment system service end and payment devices |
CN105718314B (en) | 2016-01-28 | 2019-11-05 | 腾讯科技(深圳)有限公司 | Event execution method and apparatus and system |
CN106020948B (en) * | 2016-05-10 | 2019-09-17 | 中国银联股份有限公司 | A kind of process dispatch method and device |
DK179823B1 (en) | 2016-06-12 | 2019-07-12 | Apple Inc. | Devices, methods, and graphical user interfaces for providing haptic feedback |
DK201670737A1 (en) | 2016-06-12 | 2018-01-22 | Apple Inc | Devices, Methods, and Graphical User Interfaces for Providing Haptic Feedback |
CN106296137A (en) * | 2016-08-01 | 2017-01-04 | 孙恩龙 | A kind of payment data processing method, Apparatus and system |
DK201670720A1 (en) | 2016-09-06 | 2018-03-26 | Apple Inc | Devices, Methods, and Graphical User Interfaces for Generating Tactile Outputs |
DK179278B1 (en) | 2016-09-06 | 2018-03-26 | Apple Inc | Devices, methods and graphical user interfaces for haptic mixing |
CN111539699B (en) * | 2016-09-20 | 2024-03-29 | 徐蔚 | Payment method and device based on multiple coding media and mobile terminal |
CN113435878A (en) | 2016-12-05 | 2021-09-24 | 创新先进技术有限公司 | Information interaction method and device |
CN107067240B (en) * | 2016-12-12 | 2020-09-08 | 创新先进技术有限公司 | Resource allocation method and device and electronic payment method |
US11132670B1 (en) | 2016-12-16 | 2021-09-28 | Worldpay, Llc | Systems and methods for performing payment transactions using indicia-based associations between user interfaces |
CN108347469B (en) * | 2017-01-24 | 2021-11-16 | 西门子公司 | Method, device and system for transmitting article information in Internet of things |
DK201770372A1 (en) | 2017-05-16 | 2019-01-08 | Apple Inc. | Tactile feedback for locked device user interfaces |
KR20230135684A (en) * | 2017-05-22 | 2023-09-25 | 엔체인 홀딩스 리미티드 | Secure provision of undetermined data from an undetermined source into the locking script of a blockchain transaction |
CN107705108A (en) * | 2017-09-15 | 2018-02-16 | 公安县凯翔网络软件开发有限公司 | Overseas prepaid mobile phone recharging platform |
JP7035434B2 (en) * | 2017-10-02 | 2022-03-15 | 株式会社デンソーウェーブ | Payment system |
CN109802916B (en) * | 2017-11-16 | 2022-04-15 | 财付通支付科技有限公司 | Resource transfer method, system, server and computer readable storage medium |
CN108197930B (en) * | 2017-12-13 | 2023-10-20 | 创新先进技术有限公司 | DOI display and transaction information verification method, device and equipment |
CN108536739B (en) * | 2018-03-07 | 2021-10-12 | 中国平安人寿保险股份有限公司 | Metadata sensitive information field identification method, device, equipment and storage medium |
CN110535809B (en) * | 2018-05-25 | 2021-08-31 | 腾讯科技(深圳)有限公司 | Identification code pulling method, storage medium, terminal device and server |
CN109034759B (en) * | 2018-06-21 | 2022-02-11 | 腾讯科技(深圳)有限公司 | Data transfer method and related equipment |
US11468427B2 (en) * | 2018-08-29 | 2022-10-11 | Mastercard International Incorporated | Systems and methods for use in contactless communication |
CN111242605B (en) * | 2018-11-29 | 2023-09-19 | 中国移动通信集团广东有限公司 | Mobile payment method |
CN109657179B (en) * | 2018-12-07 | 2024-04-16 | 北京奇虎科技有限公司 | Service processing method, system and storage medium |
US11276106B2 (en) | 2018-12-11 | 2022-03-15 | Wells Fargo Bank, N.A. | System and method for claw back and price protection |
CN111159615B (en) * | 2019-12-31 | 2024-01-02 | 新方正控股发展有限责任公司 | Webpage processing method and device |
CN111275543B (en) * | 2020-01-17 | 2023-06-23 | 北京字节跳动网络技术有限公司 | Information processing method, device, server and storage medium |
TWI786375B (en) * | 2020-02-14 | 2022-12-11 | 財金資訊股份有限公司 | Data Protection System and Method for Mobile Phone Number Agreed Transfer |
CN111429145B (en) * | 2020-03-26 | 2022-04-01 | 深圳市腾讯计算机系统有限公司 | Risk control method and device for electronic transaction and electronic equipment |
US11316843B1 (en) * | 2020-03-31 | 2022-04-26 | Amazon Technologies, Inc. | Systems for authenticating users from a separate user interface |
US11244314B2 (en) * | 2020-04-13 | 2022-02-08 | Paypal, Inc. | Dual controls for processing electronic transactions |
CN113839851A (en) * | 2020-06-08 | 2021-12-24 | 腾讯科技(深圳)有限公司 | Payment configuration method and device |
CN111815446A (en) * | 2020-07-06 | 2020-10-23 | 泰康保险集团股份有限公司 | Electronic transaction method, system and storage medium |
CN112258168A (en) * | 2020-10-23 | 2021-01-22 | 中智关爱通(上海)科技股份有限公司 | Payment method, system and readable storage medium based on user digital wallet |
CN113095809A (en) * | 2021-03-31 | 2021-07-09 | 聚好看科技股份有限公司 | Intelligent glasses, server and payment method |
CN113807848B (en) * | 2021-09-17 | 2024-04-09 | 腾讯科技(深圳)有限公司 | Data verification method, device, computer readable storage medium and computer equipment |
US20230316168A1 (en) * | 2022-03-30 | 2023-10-05 | Bank Of America Corporation | Augmented reality device for performing concurrent multitudinous resource interactions |
Family Cites Families (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7680324B2 (en) * | 2000-11-06 | 2010-03-16 | Evryx Technologies, Inc. | Use of image-derived information as search criteria for internet and other search engines |
JP2003141433A (en) | 2001-11-07 | 2003-05-16 | Nec Corp | Settlement method and system, server device, information terminal, information processing method, and program |
US20130043305A1 (en) | 2011-07-18 | 2013-02-21 | Tiger T. G. Zhou | Methods and systems for receiving compensation for using mobile payment services |
US8985442B1 (en) | 2011-07-18 | 2015-03-24 | Tiger T G Zhou | One-touch payment using haptic control via a messaging and calling multimedia system on mobile device and wearable device, currency token interface, point of sale device, and electronic payment card |
JP2005149036A (en) | 2003-11-14 | 2005-06-09 | Fujitsu Ltd | Method for electronic commerce transaction |
JP2005267618A (en) | 2004-02-18 | 2005-09-29 | Bank Of Tokyo-Mitsubishi Ltd | Electronic commerce support device and program |
CN1798204A (en) | 2004-12-24 | 2006-07-05 | 华为技术有限公司 | Payment system and implement method |
EP2008236A4 (en) * | 2006-04-03 | 2011-10-05 | Ebiz Mobility Ltd | Method for universal electronic payment processing |
US7739169B2 (en) | 2007-06-25 | 2010-06-15 | Visa U.S.A. Inc. | Restricting access to compromised account information |
CN101110819A (en) * | 2007-08-03 | 2008-01-23 | 中国网络通信集团公司 | Method for improving switching speed when browsing pages |
KR20090016164A (en) | 2007-08-10 | 2009-02-13 | 김창모 | Web service system and its method providing chatting service, electronic trade service, and advertising service using script code inserted in product page by seller |
US8539337B2 (en) * | 2008-02-21 | 2013-09-17 | International Business Machines Corporation | Internet services and methods thereof |
US9245263B2 (en) * | 2009-06-23 | 2016-01-26 | Jwl Ip Holdings Llc | Systems and methods for scripted content delivery |
US8429048B2 (en) | 2009-12-28 | 2013-04-23 | Visa International Service Association | System and method for processing payment transaction receipts |
US8380177B2 (en) | 2010-04-09 | 2013-02-19 | Paydiant, Inc. | Mobile phone payment processing methods and systems |
US20120028609A1 (en) | 2010-07-27 | 2012-02-02 | John Hruska | Secure financial transaction system using a registered mobile device |
WO2012073014A1 (en) * | 2010-11-29 | 2012-06-07 | Mobay Technologies Limited | A system for verifying electronic transactions |
AU2012217606A1 (en) * | 2011-02-16 | 2013-05-09 | Visa International Service Association | Snap mobile payment apparatuses, methods and systems |
US20120215700A1 (en) | 2011-02-18 | 2012-08-23 | Vivonet, Inc. | Payment systems and methods using mobile computing devices |
KR101245105B1 (en) | 2011-03-23 | 2013-03-25 | 주식회사 시큐브 | Method and System for Authentication in Electronic commerce using Smart Phone |
CN103106576A (en) * | 2011-11-15 | 2013-05-15 | 腾讯科技(深圳)有限公司 | Payment method and payment system based on client side and payment client side |
US20130173465A1 (en) | 2011-11-27 | 2013-07-04 | Fortumo OU | System and method to facilitate purchases on mobile devices via automatic payment confirmation |
WO2013093864A1 (en) * | 2011-12-23 | 2013-06-27 | Prosense Technology (Proprietary) Limited | Electronic signature authentication method and system |
US8935777B2 (en) * | 2012-02-17 | 2015-01-13 | Ebay Inc. | Login using QR code |
KR101671457B1 (en) | 2012-04-18 | 2016-11-01 | 구글 인코포레이티드 | Processing payment transactions without a secure element |
TW201349127A (en) * | 2012-05-17 | 2013-12-01 | jun-yu Zhu | Dynamic barcode verification system and its verification method |
US9704148B2 (en) | 2012-07-27 | 2017-07-11 | @Pay Ip Holdings Llc | Email payment gateway for e-commerce |
WO2014059142A1 (en) | 2012-10-10 | 2014-04-17 | Mastercard International Incorporated | Methods and systems for conducting remote point of sale transactions |
CN102968717A (en) * | 2012-11-07 | 2013-03-13 | 华为技术有限公司 | Electronic payment method, relevant device and system |
US9483286B2 (en) * | 2013-03-15 | 2016-11-01 | Avi Networks | Distributed network services |
CN103218715A (en) | 2013-03-26 | 2013-07-24 | 苏州通付盾信息技术有限公司 | Dynamic payment code implementation method in cloud payment system |
-
2014
- 2014-05-15 CN CN201410205929.8A patent/CN105099688B/en active Active
- 2014-05-15 CN CN201910058547.XA patent/CN110009315A/en active Pending
- 2014-09-24 TW TW103132965A patent/TWI665619B/en active
-
2015
- 2015-05-12 US US14/710,075 patent/US10902393B2/en active Active
- 2015-05-13 KR KR1020197001131A patent/KR102218168B1/en active IP Right Grant
- 2015-05-13 JP JP2016562800A patent/JP6509253B2/en active Active
- 2015-05-13 EP EP15724485.6A patent/EP3143571A1/en not_active Ceased
- 2015-05-13 KR KR1020167028643A patent/KR20160134770A/en active Search and Examination
-
2016
- 2016-02-04 HK HK16101347.0A patent/HK1213392A1/en unknown
-
2020
- 2020-11-18 US US16/951,901 patent/US20210073761A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
CN105099688B (en) | 2018-12-21 |
KR20190006613A (en) | 2019-01-18 |
KR20160134770A (en) | 2016-11-23 |
KR102218168B1 (en) | 2021-02-24 |
CN110009315A (en) | 2019-07-12 |
JP2017516206A (en) | 2017-06-15 |
TW201543386A (en) | 2015-11-16 |
TWI665619B (en) | 2019-07-11 |
JP6509253B2 (en) | 2019-05-08 |
CN105099688A (en) | 2015-11-25 |
EP3143571A1 (en) | 2017-03-22 |
US10902393B2 (en) | 2021-01-26 |
US20150332226A1 (en) | 2015-11-19 |
HK1213392A1 (en) | 2016-06-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210073761A1 (en) | Method, apparatus, and system for operating an electronic account in connection with an electronic transaction | |
KR102141836B1 (en) | Two factor authentication | |
US20210150506A1 (en) | Peer-to-peer payment systems and methods | |
WO2015175619A1 (en) | Method, apparatus, and system for operating an electronic account in connection with an electronic transaction | |
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 | |
US20150163186A1 (en) | Launching a client application based on a message | |
US20120290468A1 (en) | Method and apparatus for secure payment using a network-connectable device | |
AU2024200211A1 (en) | Dynamically rendered interface elements during online chat sessions | |
RU2769946C2 (en) | System for secure remote transactions using mobile apparatuses | |
CN114096981A (en) | Authenticating voice transactions using payment cards | |
AU2022263531A1 (en) | Automated data tokenization through networked sensors | |
US20180181963A1 (en) | Method and system for purchase precheck | |
US11301360B2 (en) | System and method for using an unobtrusive and discrete embedded barcode for debugging | |
WO2019025868A1 (en) | System and method for providing secured services | |
TWM564769U (en) | Authorized store voice payment system | |
NL2025516B1 (en) | Methods and systems for transferring funds | |
KR102394694B1 (en) | Payment server, payment system and card registration method thereof | |
WO2016033144A1 (en) | Method and system for exchanging information | |
JP2023096292A (en) | Service management system, transaction server, and service management method | |
TW201946001A (en) | Authorized store voice payment system including a communication unit, a display unit, a processing unit, an image recognition module, and a voice recognition module |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: APPLICATION DISPATCHED FROM PREEXAM, NOT YET DOCKETED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
AS | Assignment |
Owner name: ADVANCED NOVA TECHNOLOGIES (SINGAPORE) HOLDING PTE. LTD., SINGAPORE Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ADVANCED NEW TECHNOLOGIES CO., LTD.;REEL/FRAME:066869/0513 Effective date: 20240308 |