[go: up one dir, main page]

WO2013012876A1 - Appareils, procédés et systèmes de plateforme de commande pour marchands - Google Patents

Appareils, procédés et systèmes de plateforme de commande pour marchands Download PDF

Info

Publication number
WO2013012876A1
WO2013012876A1 PCT/US2012/047092 US2012047092W WO2013012876A1 WO 2013012876 A1 WO2013012876 A1 WO 2013012876A1 US 2012047092 W US2012047092 W US 2012047092W WO 2013012876 A1 WO2013012876 A1 WO 2013012876A1
Authority
WO
WIPO (PCT)
Prior art keywords
merchant
campaign
information
mcp
user
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.)
Ceased
Application number
PCT/US2012/047092
Other languages
English (en)
Inventor
Edward Katzin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Visa International Service Association
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa International Service Association filed Critical Visa International Service Association
Publication of WO2013012876A1 publication Critical patent/WO2013012876A1/fr
Anticipated expiration legal-status Critical
Priority to US14/230,327 priority Critical patent/US10438176B2/en
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present innovations generally address apparatuses, methods, and systems for electronic transactions, and more particularly, include MERCHANT CONTROL PLATFORM APPARATUSES, METHODS AND SYSTEMS ("MCP").
  • a merchant is a manufacturer, a retailer or a distributor who produces, distributes or sells products. Consumers may shop with a merchant for products and pay for the product at a point of sale (POS) terminal at the merchant store to complete the purchase. Merchants who allow a consumer to pay with a credit card need to register for credit card payment. A merchant may send personnel to a local bank branch to interact with a bank representative to establish a credit card payment channel for the merchant store. Upon registration, the merchant can attach a label "major credit card accepted" at its POS terminal so that a consumer can pay by credit cards.
  • POS point of sale
  • FIGURES lA-B show block diagrams illustrating example aspects of the MCP
  • FIGURES 2A-2B show a block diagram illustrating data flows between MCP affiliated entities within embodiments of MCP; [ 0009 ] FIGURES 3A-3H provide logic flow diagrams illustrating consumer merchant onboarding within embodiments of the MCP; [ 0010 ] FIGURES 4 provides a logic flow diagram illustrating merchant analytics based campaign set up within embodiments of the MCP; [ 0011] FIGURES 5 and 6A-6F provide exemplary user interface diagrams illustrating example aspects of merchant analytics and campaign set-up with the MCP; [ 0012 ] FIGURES 7A-22B show user interface diagrams illustrating example aspects of merchant control platform in some embodiments of the MCP; [ 0013 ] FIGURES 23A-26C show user interface diagrams illustrating example aspects of merchant onboarding in some embodiments of the MCP; [ 0014] FIGURES 27-3 oC show logic flow diagrams illustrating example aspects of merchant services upon onboarding in some embodiments of the MCP;
  • FIGURE 31 shows a datagraph diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout (“UPC”) component into a checkout data display output;
  • FIGURE 32 shows a logic flow diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout (“UPC") component into a checkout data display;
  • FIGURES 33A-B show datagraph diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization (“PTA”) component into a purchase transaction receipt notification;
  • FIGURES 34A-B show logic flow diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization (“PTA”) component into a purchase transaction receipt notification;
  • FIGURES 35A-B show datagraph diagrams illustrating example aspects of transforming a merchant transaction batch data query via a Purchase Transaction Clearance (“PTC”) component into an updated payment ledger record;
  • PTC Purchase Transaction Clearance
  • MCP The MERCHANT CONTROL PLATFORM APPARATUSES, METHODS AND SYSTEMS
  • MCP provides an advertising tracking and payment platform which combines online tracking of consumer behaviors and merchant advertising into purchase data.
  • MCP may provide a platform for a merchant to automatically enroll with a payment platform (e.g., Visa V.me wallet service, etc.), and provide consumer purchasing analytics for the merchant to devise a campaign.
  • a payment platform e.g., Visa V.me wallet service, etc.
  • the MCP payment processing component may be integrated with an digital/electronic wallet (e.g., a Visa V-Wallet, etc.), comprise a separate stand alone component instantiated on a user device, comprise a server/cloud accessed component, be loaded on a smart/prepaid card that can be substantiated at a PoS terminal, an ATM, a kiosk, etc., which may be accessed through a physical card proxy, and/or the like.
  • the MCP may provide a merchant configuration UI for a merchant to create a campaign, set ad revenue sharing rules, and/or the like.
  • the MCP may provide a merchant information collecting page based on the merchant type. In this way, the MCP reduces redundant information for merchant enrollment, and thus improves network transmission and processing efficiency.
  • MCP MERCHANT CONTROL PLATFORM
  • FIGURES 1A-1B provide block diagrams illustrating example aspects of merchant onboarding and merchant campaign analytics within embodiments of the MCP.
  • various merchants may register with a payment platform ii4a-b, e.g., the Visa V.me wallet payment platform, and/or the like, an online shopping site (e.g., Amazon.com, shop.com, etc.), and/or the like.
  • the MCP may generate customized registration forms via a user interface (UI), e.g., a web-based application, a mobile UI, and/or the like.
  • UI user interface
  • a merchant may comprise a large business, e.g., "Terry luxury Department Store” 150a with an online shopping site (e.g., www.terry-luxury.com ' ), and/or a small business such as an individual seller 150b.
  • the MCP server 120 may evaluate the type of the merchant and determine the required information for registration based on the merchant type 116.
  • the merchant may receive a merchant registration page 118a
  • the merchant may receive a seller registration page 118b, which may require
  • the MCP server 120 may provide an analytics platform to the
  • the merchant may circle or tap on a "weak" spot on a sales curve, e.g., 139, to indicate
  • a merchant 25oa-b may operate a wide variety of
  • the merchant may provide 28 different user devices, including communications devices and technologies within 1 embodiments of MCP operation.
  • the merchant may request to create a user device, including communications devices and technologies within 1 embodiments of MCP operation.
  • the merchant may request to create a user device, including communications devices and technologies within 1 embodiments of MCP operation.
  • the merchant may request to create a user device, including communications devices and technologies within 1 embodiments of MCP operation.
  • the MCP component may be instantiated on a
  • 9 may be a remote server which is accessed by the merchants 25oa-b via a communication
  • network 213, such as, but not limited to local area network (LAN), in-house intranet, the LAN 10 network 213, the LAN 10 network 213, such as, but not limited to local area network (LAN), in-house intranet, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the Internet 10 network 213, such as, but not limited to local area network (LAN), in-house intranet, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 213, the LAN 10 network 21
  • the merchant device e.g., a web
  • the MCP server 220 may identify a type of the merchant and retrieve registration pages based on the merchant type 227 (e.g., whether the merchant is a sole proprietor, a registered company, etc.). In one implementation, the MCP server 220 may provide registration pages for business 23ia-b (e.g. see FIGURES 24A-24C) to the merchant 250a-b for the merchant to provide requested information 232a-b. In one implementation, with reference to FIGURE 25, the registration pages 23ia-b may vary based on requirement of an issuer, as different issuer may require different requirements to register. The MCP may automatically inquire the issuer's informational requirements in an issuer database, and generate a form for the merchant so as to require the requisite information automatically. For example, the merchant may provide information including, but not limited to company/seller information, customer service information, primary contact information, term of service, payment information, and/or the like.
  • the merchant may provide information including, but not limited to company/seller information, customer service information, primary contact information, term of service,
  • the merchant device may provide a profile information message 232a for a sole proprietor to the MCP server 220 as a HTTP(S) POST message including XML-formatted data.
  • a profile information message 232a for a sole proprietor may be provided below:
  • the merchant 250b may provide a federal tax ID (EIN) instead of the social security number.
  • EIN federal tax ID
  • the MCP server 220 may provide an account verification request message 235 to a payment network 240 as a HTTP(S) POST message including XML-formatted data.
  • HTTP(S) POST message including XML-formatted data.
  • an example verification request may include request for bankruptcy information, back tax in recent years, liens, Better Business Bureau violations, Done in Brandstreet report, and/or the like.
  • An example listing of a merchant registration request message 235 for a business merchant, substantially in the form of a HTTP(S) POST message including XML-formatted data, is provided below:
  • the payment network 240 may generate a response 236 to confirm the financial status of the merchant's account for registration.
  • the payment network 240 may provide an account verification response message 236 to the MCP server 220 as a HTTP(S) POST message including XML-formatted data.
  • HTTP(S) POST message including XML-formatted data.
  • the verification response for a business merchant may comprise a message substantially in the form of a HTTP(S) POST message including XML-formatted data, is provided below:
  • the MCP server 220 may generate and store a merchant record to the
  • the MCP server 220 may send a checkout widget
  • a checkout lightbox e.g., a checkout lightbox
  • 25 checkout widget 234 may comprise a block of XML codes in the form similar to the
  • the MCP server 200 may provide analytics based merchant campaign set-up to merchants 250.
  • a merchant may submit an analytics request 255a, e.g., via a client device 203.
  • the client device 203 may forward the analytics request 255b to the MCP server 220.
  • the merchant device e.g., a web browser instantiated on a merchant computer, etc.
  • FIGURES 5 and 6A-6B may be used by the merchant to select various parameters for which they are interested in obtaining analytics, and once the user makes a request, e.g., clicking a button 522-523 in FIGURE 5, the MCP may generate the analytics request message.
  • An example listing of a merchant analytics request message 255b, substantially in the form of a HTTP(S) POST message including XML-formatted data, is provided below:
  • the MCP server 220 may generate a transaction inquiry 261 to a payment
  • the MCP server 220 may access a transaction database
  • the transaction inquiry may be any transaction inquiry.
  • the transaction inquiry may be any transaction inquiry.
  • the MCP server 220 may issue PHP/SQL commands
  • FIGURE 37 transactions table
  • the MCP server 220 may generate performance
  • 15 jqPlug, etc. are example charting library kits that may obtain inquiry results for user
  • FIGURES 7A-7C various graphic representations via a UI (e.g., see FIGURES 7A-7C).
  • the merchant 250 may indicate an interested spot
  • the merchant interested spots message For example, in one implementation, the merchant interested spots message
  • 22 269 may comprise information such as a start date and an end date of the merchant
  • the user selection may be represented by a Cartesian
  • 29 merchant may move a mouse around a graphic representation of sales performance
  • the MCP may generate a heuristics
  • each of the stackable blocks in FGIURES 6A-6F may have its own set of parameters, and may modify constraints on any generated campaign, and a merchant may stack a few or as many of such constraints as desired.
  • the merchant has set a campaign for all products of the brand "La Mer" for all returning customers, and new customers who has purchased any "La Mer" products at stores other than "Terry luxury," and/or are frequent buyers of skin care products.
  • the MCP server 220 may then generate a campaign plan 277 and distribute the campaign plan 276 with the campaign parameters 275 to various media channels, e.g., social media 260a, websites 260b, TV/radio 260c, and/or the like.
  • the campaign parameters may be compiled and stored with a merchant profile. These settings may be used to author, e.g., advertising campaign expenditures, etc., in 1 various segments, demographics, target consumer groups, and/or the like. For example,
  • the dashboard 503 identifies the weak performance of southern region
  • 8 campaign block may be pre-populated, suggesting ads spend restricted to southern
  • FIGURES 3A-3C provide exemplary logic flow diagrams illustrating
  • a merchant may access a MCP onboarding platform 302, e.g., via a web-based MCP onboarding platform 302, e.g., via a web-based MCP onboarding platform 302, e.g., via a web-based MCP onboarding platform 302, e.g., via a web-based MCP onboarding platform 302, e.g., via a web-based MCP onboarding platform 302, e.g., via a web-based
  • FIGURE 23A 14 MCP onboarding platform is provided in FIGURE 23A, and a merchant may enter an
  • a merchant may submit merchant login request
  • the MCP 18 onboarding process (e.g., see 2310 in FIGURE 23B).
  • the MCP 18 onboarding process
  • a merchant may select whether it accepts credit cards payment with
  • the MCP may proceed to determine a merchant type 312. For
  • a merchant may select a "personal" 2311 or business
  • the merchant is a business merchant (e.g., a manufacturer, a
  • the MCP may generate an onboarding form for business
  • 27 D comprise information such as company information 2320, contact information, an
  • the MCP may determine whether the merchant is an individual.
  • 31 MCP may populate profile information 314c from the individual's wallet profile into a 1 registration page if the individual attempts to register as a merchant. If the individual
  • the MCP may generate an onboarding form for
  • profile information e.g., including user name, address, contact
  • identification information such as the social security, etc., 341b.
  • the merchant may be denied enrollment (e.g., see 2325 in FIGURE 23E), and/or
  • the MCP may proceed
  • the MCP upon generating the merchant account, the MCP
  • 11 may generate onboarding form based on merchant type 312 (e.g., the merchant may
  • FIGURE 24C a corporate LLC
  • merchant onboarding form may request merchant information such as the EIN.
  • an individual merchant may need to submit SSN information 314b for
  • the MCP may request the merchant to identify is a credit card processor or merchant account provider, and the account number, e.g., see
  • the merchant may identify types of payment it accept, e.g.,
  • 23 information 316 e.g., an EIN for business merchants, SSN for individual merchants,
  • the MCP may look up issuer application informational
  • the MCP may
  • 29 processing network e.g., Visa Net, etc.
  • merchant verification 325 may perform merchant verification 325
  • such 1 verification request may be sent to a third party background/credit check entity.
  • the merchant verification request may be passed on to a third party
  • the payment network may generate a
  • the MCP may generate a merchant enrollment record 333 (e.g., see 233 in
  • FIGURE 2A 9 FIGURE 2A
  • deliver a registration complete page to the merchant e.g., see
  • the merchant may receive a denial notice 332, e.g., due to
  • the MCP may instantiate merchant record for merchant
  • 15 lightbox checkout e.g., FIGURES 10A-12B, and/or the like.
  • API generation request may submit an API generation request with is access ID 345, e.g., a request to generate a "V.me” checkout lightbox (e.g., see merchant
  • the MCP server may verify whether the merchant
  • the MCP server may proceed to retrieve a list of API options 349, such as
  • the user may select an API category 351, based on
  • API parameters e.g., I305a-f in FIGURE 13A
  • I305a-f in FIGURE 13A
  • the MCP server 28 to a user id, a partner name, and/or the like.
  • the MCP server 28 to a user id, a partner name, and/or the like.
  • 29 may query for API template from an API database 319 based on the category 354. For
  • the MCP server may retrieve
  • the MCP server may issue 1 PHP/SQL commands to query a database table (such as FIGURE 37, API table) for an
  • the query may be formatted to request a json
  • API key secret and site name may help to
  • API_key secret, token, sample_code, FROM APITable WHERE API_site_name LIKE
  • the MCP may select the appropriate template from
  • a developer at the merchant site may
  • the MCP server 310 may send the
  • FIGURES 3D-3H provide exemplary logic flow diagrams illustrating
  • a merchant may enroll at a third party processor (e.g.,
  • the enrollment request may be 1 pending review 363 with MCP. If the merchant does not qualify (e.g., low credit rating,
  • the enrollment may be rejected 364. Otherwise,
  • the merchant may be onboard 366 as a digital
  • the merchant may create application 367, e.g.,
  • creating a site e.g., see FIGURES 10A-12B
  • creating lightbox checkout widgets etc.
  • the merchant may enter settlement information 368, e.g., how a
  • MCP may perform review process with a
  • non-risky merchant e.g., an established business merchant such as "Terry luxury,” etc.
  • the non-risky merchant 370 may enter enrollment detail 371
  • the MCP may check the merchant termination list
  • 18 decision manager 386a may apply business rules 388 to verify whether the enrollment
  • a one time token/URL e.g., a confirmation URL provided in an email, etc.
  • control panel 386b may retrieve merchant profile data 383 from
  • control panel may generate API keys 389 if the merchant
  • 27 decision manager 386a may send a review required decision 390 to the MCP 372, which
  • the decision manager may then create a
  • FIGURE 3G illustrates an example of denying a fraudulent merchant within implementations of the MCP.
  • the decision manager may reject 381b the request, and deny the merchant onboarding 381c.
  • FIGURE 3H illustrates an example of merchant aborting an enrollment within implementations of the MCP.
  • the MCP may save the enrollment state 393a.
  • the MCP may retrieve an enrollment state 393b and send a session url 395 to the merchant, e.g., via email. The MCP may then load enrollment page 397 and send merchant resume data 396 to the approval process to resume enrollment.
  • FIGURE 4 provides an exemplary logic flow diagram illustrating aspects of merchant analytics and campaign set-up within embodiments of the MCP.
  • a merchant may access a MCP merchant control panel platform 402, e.g., the web-based dashboard in FIGURE 5, 7B-7C and 8A-8B, and/or a mobile control panel platform as shown at 605 in FIGURE 6A.
  • a merchant may submit an analytics request 405 (e.g., 255a-b in FIGURE 2B), whereas the MCP may retrieve transaction data 410 and query for purchasing history of the merchant specified product brand 413.
  • the merchant may specify performance data within interested product category (e.g., 621 in FIGURE 6A), per store(e.g., 623 in FIGURE 6A), per customer (e.g., 622 in FIGURE 6A), and/or the like.
  • the MCP may query on the transaction history to retrieve relevant transaction data (e.g., see 261 in FIGURE 2B) and generate merchant analytics and heuristics 415.
  • relevant transaction data e.g., see 261 in FIGURE 2B
  • merchant analytics and heuristics 415 e.g., see 261 in FIGURE 2B
  • the MCP may flag a percentage of total transactions by state, e.g., the state that has the highest percentage, etc.
  • Flotr Chart, jfree chart, etc. are example library kits that may obtain 1 inquiry results for user chart interaction mechanisms.
  • the merchant may receive graphic representation
  • the MCP may generate
  • the MCP may
  • the MCP may generate
  • the MCP may generate a pre-populated campaign
  • the merchant may further specify campaign parameters 429,
  • the MCP may generate a campaign plan based on
  • FIGURE 5 provides an exemplary web based UI for a merchant control
  • a merchant may access a dashboard page 503 within a browser
  • campaigns 505 e.g., to generate analytics on consumer's loyalty purchases, etc.
  • analytics 506 e.g., for a merchant to set up a campaign, etc.
  • the merchant control panel dashboard may
  • merchant profile information 507 e.g., merchant name, picture, URL, business category, contact phone number, etc.
  • a merchant may elect edit 508 the profile information on the dashboard page.
  • the merchant may elect to view real-time transactions 520, which illustrates to the merchant "who is buying” 522 (e.g., consumer demographics, geographical distribution, etc.), "buying what” 523 (e.g., popular transaction product, etc.).
  • real-time transactions 520 which illustrates to the merchant "who is buying” 522 (e.g., consumer demographics, geographical distribution, etc.), "buying what” 523 (e.g., popular transaction product, etc.).
  • the merchant dashboard may provide a campaign section for a merchant to click to set a new campaign 516, and/or update a campaign 517.
  • the merchant may view the current campaign performance 518 via a bar chard displayed. Further implementations of the campaign set-up are provided in FIGURES 6B-6D.
  • the merchant dashboard may provide consumer feedbacks from social platforms 521, e.g., Facebook, Twitter, Amazon, etc., including consumer comments about the product and user ratings, etc.
  • social platforms 521 e.g., Facebook, Twitter, Amazon, etc.
  • FIGURES 6A-6F provide exemplary mobile UIs for a merchant control panel within embodiments of the MCP.
  • a merchant e.g., "Terry luxury” 605
  • general information may provide a view of sales performance, e.g., the number of customers over a period of time 608, etc.
  • the merchant may further elect to view "who's buying” 609, which may provide a view of consumer demographics, geographical distribution information, etc.; "buying what" 610, the current sales performance and popular products, etc.; offering 611 and campaign updates 612. 1 [0083] For example, in one implementation, if the merchant tap on the option
  • the MCP may provide a product chart 615, which shows various
  • the MCP may list products
  • a merchant may click to expand 619 for more analytics options, e.g., for the product
  • a listed retail store may be expanded to show several options, e.g.,
  • 19 sales performance curve may be provided to show the number of purchase over a period
  • the merchant may further view a taxonomy of the customers as new to a specific
  • a performance sales curve may be
  • customers may be grouped as new to both the merchant store and a specific
  • 5 performance curves as 638 may be provided once the merchant taps on the panel.
  • a merchant may select a "Campaign" tab
  • the merchant control panel to set up a product campaign.
  • the merchant control panel to set up a product campaign.
  • 8 campaign panel may allow a merchant to configure the featured products of the
  • a merchant may tap on the "feature product"0 panel 643 to expand to view a list of product categories, such as, but not limited to1 cosmetics 645a, skin care 645b, perfume 645c, and/or the like.
  • product categories such as, but not limited to1 cosmetics 645a, skin care 645b, perfume 645c, and/or the like.
  • the merchant may tap to expand to configure sub-categories. For example,3 under the product category "skin care" 645b, the merchant may tap to view a sub-list of4 products 646a-f, and the merchant may slide the "on/off button to determine whether5 to include such products into the campaign.
  • the campaign panel may allow a merchant to7 configure the campaign type 650.
  • the campaign may have various types of8 offers to the consumers, such as loyalty punch card 651a (e.g., a consumer may obtain9 discount once he/she has purchased a count of units, etc.; see 651a in FIGURE 6D), pre-0 purchase discount (e.g., the consumer may enjoy a discount for the first purchase, etc.;1 see 651b in FIGURE 6D) 651b, geographical/store based discount 651c, offers for2 existing customers 6sid (e.g., see 651c in FIUGRE 6E), customized packages 651 ⁇ to3 targeted consumers (e.g., consumers whose purchasing records show an interest into4 beauty products, etc.; see 651 ⁇ in FIGURE 6E), units for the campaign 6sif (e.g., see5 65if in FIGURE 6D), campaign time duration 6sig (e.g., see 6sig in FIGURE 6D), and
  • a merchant may expand a loyalty0 punch card panel to set the discount percentage 652a and punch units 652b with sliding1 bars 652a-b.
  • the merchant panel may display a summary of the 1 offer, e.g., "an additional 25% discount off your next purchase for every 6 La Mer
  • a merchant may select to save the card 652d, and/or to start a new
  • a merchant may expand a pre-purchase discount panel to set the
  • the merchant panel may display a summary of the offer, e.g., "an
  • a merchant may select to save the offer 653d, and/or to start a new
  • a merchant may expand a units panel to set the performance
  • a merchant may select to save the units
  • a merchant may expand a time configuration panel to set the
  • 18 campaign duration 655a offer waiting period for first-time consumers 655b (e.g., a new
  • a merchant may select to save the time configuration 655d, and/or to
  • the MCP may generate a recommended value for parameter
  • the MCP may return 1 suggested discount rate of "25%” for every "16 La Mer products" as default parameters.
  • a merchant may expand a
  • 4 merchant may check to select a specific store location 661a from a drop-down list, may
  • select all stores within a state 661b may select all stores within a zipcode range 661c,
  • the selected states may appear in red circles to reflect selecting southern
  • a merchant may expand a customized package panel to set the
  • the merchant may select target customers 665a as who
  • the merchant may also group consumers who are interested in
  • the merchant may
  • the merchant may configure various campaign
  • the merchant may set each of the listed goal parameters
  • the merchant may configure campaign/ad
  • the merchant may select a list of available
  • online channels such as social media platforms 69ia-c, shopping sites (e.g.,
  • the merchant may expand the "other" section 693 to enter a customized ad
  • FIGURES 7A-7C provide exemplary merchant control panel UIs
  • FIGURE yA a merchant may access the dashboard site to create a merchant shopping site 710 upon registration.
  • a merchant may view sales performance over a period of time, e.g., number of transactions (e.g., see FIGURE 7B), number of return transactions by state (e.g., see FIGURE 7C), etc.
  • the MCP may generate heuristics to flag a state that has the highest market share, e.g., see 710/715 in FIGURES 7B-C.
  • FIGURES 8A-8B provide exemplary merchant control panel UIs illustrating aspects of MCP reporting statistics within embodiments of the MCP.
  • a merchant may elect to generate sales data within a selected period of time, e.g., activity per day 805.
  • a merchant may select to view sales data performance of different category, e.g., an aggregated performance curves of different merchant sites 815, and a pie chart distribution 825, and/or the like.
  • the MCP may generate heuristics, e.g., to flag a site that has the highest sales share, e.g., see 825.
  • FIGURES 9A-9H provide exemplary merchant control panel UIs illustrating aspects of MCP merchant transaction search within embodiments of the MCP.
  • a merchant may enter search criteria to search a transaction within a period of time, e.g., 905 at FIGURE 9A.
  • a merchant may view multiple search results that list the the transaction details of transactions satisfying the search criteria, as shown in FIGURE 9B.
  • a merchant may authorize a pending transaction, as shown in FIGURE 9C.
  • a merchant may authorize a pending transaction, as shown in FIGURE 9C.
  • a merchant may confirm a transaction, as shown in FIGURE 9D.
  • a merchant may authorize a refund request, as shown in FIGURE 9E.
  • a merchant may void a pending transaction upon validating a refund, as shown in FIGURE 9F.
  • the MCP may update a list of transactions, showing the merchant's latest edits of the transactions (e.g., to authorize, to capture, to allow refund, etc.), as shown at 920 in FIGURE 9G.
  • a merchant may edit the date range for transaction searches, as shown at 925 in FIGURE 1 9H.
  • FIGURES loA-ioC provide exemplary merchant control panel UIs
  • a merchant may create a shopping site via MCP
  • a merchant may create a list of merchant sites ioo8a-b by establishing
  • FIGURES 11A-11B provide exemplary merchant control panel UIs
  • a merchant may enter a site name to create a new site
  • FIGURES 12A-12C provide exemplary merchant control panel UIs
  • 16 merchant may edit site parameters such as site name 1205a, post-back URL 1205b, etc.,
  • the MCP may update its API key 1205c, security signature I205d, and/or the like, as is shown in FIGURES 12A-C.
  • FIGURES 13A-13D provide exemplary merchant control panel UIs
  • a merchant may create a checkout lightbox by entering a
  • the MCP may return a block of sample XML code 1310 for the
  • a merchant may enter
  • a merchant may view a purchase contract for the generated checkout
  • FIGURES 14A-16C provide exemplary merchant control panel UIs
  • a merchant may edit company information, e.g., see
  • a merchant may manage users and edit
  • FIGURES 17A-17B provide exemplary merchant control panel UIs
  • FIGURES 18A-22 provide exemplary merchant control panel UIs
  • a merchant may enter various combinations of the MCP.
  • a merchant may enter various combinations of the MCP.
  • 13 may list the enrolled merchant accounts, wherein a merchant may specify the usage
  • each account e.g., a global account or U.S. account for U.S. transactions, etc.
  • FIGURE 20 see FIGURE 20.
  • FIGURES 22A-22B provide exemplary merchant control panel UIs
  • a merchant may post notifications for offers
  • 20 merchant may view pending notifications for each site via the MCP platform, and elect
  • FIGURES 23A-26C provide exemplary merchant onboarding UIs
  • FIGURES 27-30C provide exemplary transaction flows illustrating MCP
  • processing network may keep a record of merchant transactions. As shown in FIGURE
  • a consumer 2702 may start with making a purchase using the lightbox checkout
  • the merchant 2705 may
  • the lightbox processor 2708 which may in turn 1 retrieve consumer previously established preference and account information 2725 to a
  • checkout processor 2710 e.g., Playspan platform, etc.
  • the checkout processor 2710 e.g., Playspan platform, etc.
  • 3 payment request may be processed with a checkout gateway 2715 (e.g., a Chase payment
  • processing network 2718 e.g., VisaNet, etc.
  • processing network 2718 e.g., VisaNet, etc.
  • FIGURES 42A-43 are identical to FIGURES 42A-43.
  • the checkout processor 2710 may provide a
  • FIGURE 28 provides an alternative logic flow diagram illustrating
  • processor 2810 gateway 2815, a global payment network (GPN) 2815, processing
  • 16 request message 2850 may be routed to the checkout gateway 2815 and forwarded to
  • FIGURE 29 provides an alternative logic flow diagram illustrating
  • 21 may be routed to a hosting site server 2905 upon processing from the checkout
  • FIGURES 30A-C provide alternative logic flow diagram illustrating
  • 27 merchant e.g., a merchant developer, etc.
  • the MCP may generate XML or html
  • the merchant may test 3015 the generated widget with the merchant site to examine whether the checkout widget is valid 3016a, or invalid 3016b upon site operation.
  • the merchant may enter bank account detail 3017 to the MCP panel to set up, e.g., see FIGURES 19A- 22.
  • a merchant developer may create a logo of the lightbox widget 3021 and insert the logo to a URL 3022.
  • a consumer may checkout 3023 by clicking on "continue to checkout," which may invoke the lightbox 3024 and return a lightbox logo 3025a-c to the consumer page.
  • a merchant developer may generate a lightbox widget in an alternative implementation.
  • the merchant site 3015 may generate a merchant page 3032, and generate a preview of the lightbox 3033.
  • the merchant site may store the lightbox setup with a CDN 3036.
  • a consumer may checkout with the merchant site, which may invoke a lightbox 3024a-b to display a lightbox logo to the consumer.
  • the CDN may return a merchant widget page 3035 and the populated lightbox 3025b to the consumer.
  • FIGURE 31 shows a datagraph diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout (“UPC") component into a checkout data display.
  • a user e.g., 3101a
  • the user may communicate with a merchant/acquirer (“merchant”) server, e.g., 3103a, via a client such as, but not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 3102).
  • a client such as, but not limited to: a personal computer, mobile device, television, point-of-sale terminal, kiosk, ATM, and/or the like (e.g., 3102).
  • the user may provide user input, e.g., checkout input 3111, into the client indicating the user's desire to purchase the product.
  • the user input may include, but not be limited to: a single tap (e.g., a one-tap mobile app purchasing embodiment) of a 1 touchscreen interface, keyboard entry, card swipe, activating a RFID/NFC equipped
  • 2 hardware device e.g., electronic card having multiple accounts, smartphone, tablet,
  • mouse clicks depressing buttons on a joystick/game
  • a user in a merchant store may scan a product barcode of the product via a
  • the user may select a
  • the user may request to checkout the items in the (virtual) shopping cart.
  • the user may request to checkout the items in the (virtual) shopping cart.
  • the user may request to checkout the items in the (virtual) shopping cart.
  • the user may request to checkout the items in the (virtual) shopping cart.
  • the client may generate a checkout request, e.g.,
  • HTTP(S) Hypertext Transfer Protocol
  • the merchant server may obtain the checkout
  • checkout detail e.g., XML data
  • the merchant server may utilize a parser such as the
  • the merchant server may extract product data
  • the merchant server may query, e.g.,
  • a merchant/acquirer (“merchant”) database e.g., 3103b, to obtain product data
  • the merchant database may be a
  • SQL Structured Query Language
  • PGP hypertext preprocessor
  • An example product data query 3114 substantially in the form of PHP/SQL
  • the merchant server may generate, e.g., 3116, checkout data to provide for the PoS client.
  • checkout data e.g., 3117
  • HTML HyperText Markup Language
  • the checkout data may be embodied, in part, in a Quick Response ("QR") code image that the PoS client can display, so that the user may capture the QR code using a user's device to obtain merchant and/or product data for generating a purchase transaction processing request.
  • a user alert mechanism may be built into the checkout data.
  • the merchant server may embed a URL specific to the transaction into the checkout data.
  • the alerts URL may further be embedded into optional level 3 data in card authorization requests, such as those discussed further below with reference to FIGURES 33-34.
  • the URL may point to a webpage, data file, executable script, etc., stored on the merchant's server dedicated to the transaction that is the subject of the card authorization request.
  • the object pointed to by the URL may include details on the purchase transaction, e.g., products being purchased, purchase cost, time expiry, status of order processing, and/or the like.
  • the merchant server may provide to the payment network the details of the transaction by passing the URL of the webpage to the payment network.
  • the payment network may provide notifications to the user, such as a payment receipt, transaction authorization confirmation message, shipping notification and/or the like. In such messages, the payment network may provide the URL to the user device. The user may navigate to the URL on the user's device to obtain alerts regarding the user's purchase, as well as other information such as offers, coupons, related products, rewards notifications, and/or the like.
  • An example listing of a checkout data 3117, substantially in the form of XML- formatted data, is provided below:
  • ⁇ alerts_URL>www. merchant . com/shopcarts .php?sessionID 4NFU4RG94 ⁇ /alerts_URL> ⁇ user_ID>j ohn . q. publicSgmail . com ⁇ /user_ID>
  • the PoS client may render and display, e.g., 3118, the checkout data for the user.
  • FIGURE 32 shows a logic flow diagram illustrating example aspects of transforming a user checkout request input via a User Purchase Checkout (“UPC") component into a checkout data display.
  • UPC User Purchase Checkout
  • a user may desire to purchase a product, service, offering, and/or the like (“product"), from a merchant via a merchant online site or in the merchant's store.
  • the user may communicate with a merchant/acquirer (“merchant”) server via a PoS client.
  • the user may provide user input, e.g., 3201, into the client indicating the user's desire to purchase the product.
  • the client may generate a checkout request, e.g., 3202, and provide the checkout request to the merchant server.
  • the merchant server may obtain the checkout request from the client, and extract the checkout detail (e.g., XML data) from the checkout request.
  • the merchant server may utilize a parser such as the example parsers described below in the discussion with reference to FIGURE 37.
  • the merchant server may extract product data (e.g., product identifiers), as well as available PoS client data, from the checkout request.
  • the merchant server may query, e.g., 3203, a merchant/acquirer ("merchant") database to obtain product data, e.g., 3204, such as product information, product pricing, sales tax, offers, discounts, rewards, and/or other information to process the purchase transaction and/or provide value-added services for the user.
  • product data e.g., 3204
  • the merchant server may generate, e.g., 3205, checkout data to provide, e.g., 3206, for the PoS client.
  • the PoS client may render and display, e.g., 3207, the checkout data for the user.
  • FIGURES 33A-B show datagraph diagrams illustrating example aspects of transforming a user virtual wallet access input via a Purchase Transaction Authorization ("PTA") component into a purchase transaction receipt notification.
  • PTA Purchase Transaction Authorization
  • a user e.g., 3301a
  • product a product, service, offering, and/or the like
  • the user may utilize a physical card, or a user wallet device, e.g., 3301b, to access the user's virtual wallet account.
  • the user wallet device may be a personal/laptop computer, cellular telephone, smartphone, tablet, eBook reader, netbook, gaming console, and/or the like.
  • the user may provide a wallet access input, e.g., 3311 into the user wallet device.
  • the user input may include, but not be limited to: a single tap (e.g., a one- tap mobile app purchasing embodiment) of a touchscreen interface, keyboard entry, card swipe, activating a RFID/NFC equipped hardware device (e.g., electronic card having multiple accounts, smartphone, tablet, etc.) within the user device, mouse clicks, depressing buttons on a joystick/game console, voice commands, single/multi-touch gestures on a touch-sensitive interface, touching user interface elements on a touch- sensitive display, and/or the like.
  • the user wallet device may authenticate the user based on the user's wallet access input, and provide virtual wallet features for the user.
  • the user wallet device may provide a transaction authorization input, e.g., 3314, to a point-of-sale (“PoS") client, e.g., 3302.
  • PoS point-of-sale
  • the user wallet device may communicate with the PoS client via Bluetooth, Wi-Fi, cellular communication, one- or two-way near-field communication ("NFC"), and/or the like.
  • the user may swipe the plastic card at the PoS client to transfer information from the plastic card into the PoS client.
  • the PoS client may obtain, as transaction authorization input 3314, track 1 data from the user's plastic card (e.g., credit card, debit card, prepaid card, charge card, etc.), such as the example track 1 data provided below:

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Les appareils, procédés et systèmes de plateforme de commande pour marchands (Merchant Control Platform, MCP) transforment, par le biais de composantes MCP, des données d'intégration de marchand en enregistrement d'adhésion de marchand. Dans un mode de réalisation de l'invention, un procédé consiste : à recevoir une demande d'adhésion de marchand par le biais d'une interface utilisateur ; à identifier le type du marchand ; à récupérer automatiquement un modèle d'adhésion de marchand basé sur le type de marchand identifié ; à inciter le marchand à remettre des informations d'inscription demandées par le modèle d'adhésion de marchand par le biais d'une interface utilisateur ; à obtenir les informations d'inscription remises par le marchand à partir du modèle d'adhésion de marchand par le biais de ladite interface utilisateur ; à vérifier le statut du marchand grâce à des procédures de vérification des antécédents basées sur les informations d'inscription remises ; et à générer un enregistrement d'adhésion de marchand.
PCT/US2012/047092 2011-07-17 2012-07-17 Appareils, procédés et systèmes de plateforme de commande pour marchands Ceased WO2013012876A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/230,327 US10438176B2 (en) 2011-07-17 2014-03-31 Multiple merchant payment processor platform apparatuses, methods and systems

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201161508679P 2011-07-17 2011-07-17
US61/508,679 2011-07-17
US13/278,173 2011-10-20
US201161570230P 2011-12-13 2011-12-13
US61/570,230 2011-12-13
US201261618670P 2012-03-30 2012-03-30
US61/618,670 2012-03-30

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US13/278,173 Continuation US20120215701A1 (en) 2010-10-20 2011-10-20 Flexible monetization service apparatuses, methods and systems

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/230,327 Continuation US10438176B2 (en) 2011-07-17 2014-03-31 Multiple merchant payment processor platform apparatuses, methods and systems

Publications (1)

Publication Number Publication Date
WO2013012876A1 true WO2013012876A1 (fr) 2013-01-24

Family

ID=47558432

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/047092 Ceased WO2013012876A1 (fr) 2011-07-17 2012-07-17 Appareils, procédés et systèmes de plateforme de commande pour marchands

Country Status (1)

Country Link
WO (1) WO2013012876A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104852884A (zh) * 2014-02-14 2015-08-19 中兴通讯股份有限公司 第三方支付平台的注册方法及装置、系统
WO2015126633A1 (fr) * 2014-02-19 2015-08-27 Mastercard International Incorporated Solutions de plate-forme de services commerciaux pour petites et moyennes entreprises
US20150254694A1 (en) * 2012-08-30 2015-09-10 Google Inc. System and Method for Providing Redeemable Commercial Objects in Conjunction with Geographic Imagery
US10977639B2 (en) 2016-01-25 2021-04-13 Freelancer Technology Pty Limited Adaptive gateway switching system
CN114493731A (zh) * 2020-10-26 2022-05-13 腾讯科技（深圳）有限公司 商户信息处理系统、方法和介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020016765A1 (en) * 2000-07-11 2002-02-07 David Sacks System and method for third-party payment processing
US20040054625A1 (en) * 2002-09-17 2004-03-18 First Data Corporation Method and systems for providing merchant services with right-time creation and updating of merchant accounts
US20080120194A1 (en) * 2006-10-25 2008-05-22 Joseph James Juras method of assisting a business in acquiring merchant services

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020016765A1 (en) * 2000-07-11 2002-02-07 David Sacks System and method for third-party payment processing
US20040054625A1 (en) * 2002-09-17 2004-03-18 First Data Corporation Method and systems for providing merchant services with right-time creation and updating of merchant accounts
US20080120194A1 (en) * 2006-10-25 2008-05-22 Joseph James Juras method of assisting a business in acquiring merchant services

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150254694A1 (en) * 2012-08-30 2015-09-10 Google Inc. System and Method for Providing Redeemable Commercial Objects in Conjunction with Geographic Imagery
CN104852884A (zh) * 2014-02-14 2015-08-19 中兴通讯股份有限公司 第三方支付平台的注册方法及装置、系统
EP3107256A4 (fr) * 2014-02-14 2017-03-01 ZTE Corporation Procédé, dispositif et système d'inscription pour plate-forme de paiement de tiers
WO2015126633A1 (fr) * 2014-02-19 2015-08-27 Mastercard International Incorporated Solutions de plate-forme de services commerciaux pour petites et moyennes entreprises
US10977639B2 (en) 2016-01-25 2021-04-13 Freelancer Technology Pty Limited Adaptive gateway switching system
CN114493731A (zh) * 2020-10-26 2022-05-13 腾讯科技（深圳）有限公司 商户信息处理系统、方法和介质

Similar Documents

Publication Publication Date Title
US10438176B2 (en) Multiple merchant payment processor platform apparatuses, methods and systems
US12277537B2 (en) Multi-directional wallet connector apparatuses, methods and systems
US10419529B2 (en) Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US10853797B2 (en) Cloud-based virtual wallet NFC apparatuses, methods and systems
US11010753B2 (en) Electronic wallet checkout platform apparatuses, methods and systems
US11037138B2 (en) Third-party value added wallet features and interfaces apparatuses, methods, and systems
US10354240B2 (en) Multi-directional wallet connector apparatuses, methods and systems
US20200094133A1 (en) Dynamic payment optimization apparatuses, methods and systems
US20160063486A1 (en) Wallet Service Enrollment Platform Apparatuses, Methods and Systems
US20130054454A1 (en) Wallet Service Enrollment Platform Apparatuses, Methods and Systems
AU2019200041A1 (en) Multi-channel remote payment apparatuses, methods and systems
US20150154588A1 (en) Reversed User Account Generation Apparatuses, Methods and Systems
AU2012223415A1 (en) Secure anonymous transaction apparatuses, methods and systems
WO2013009660A1 (fr) Appareils, procédés et systèmes de plate-forme d'incitation ciblée et à notifications réduisant la largeur de bande bidirectionnelle
WO2013012876A1 (fr) Appareils, procédés et systèmes de plateforme de commande pour marchands

Legal Events

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

Ref document number: 12814535

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12814535

Country of ref document: EP

Kind code of ref document: A1