Note: Descriptions are shown in the official language in which they were submitted.
CA 03111997 2021-03-05
WO 2020/068405 PCT/US2019/050250
STORED BALANCE WITH MULTI-CHANNEL WITHDRAWAL ACCESS
PRIORITY
[0001] This application claims priority to U.S. Patent Application Nos.
16/147,080, 16/146,973, and 16/147,152,
all filed on September 28, 2018, the entire contents of which are incorporated
by reference herein.
BACKGROUND
[0002] Payment instruments are used in a wide variety of transactions.
Examples of such payment instruments
include credit cards, stored value cards, debit cards, loyalty cards, library
cards, membership cards, and the like. The
information displayed on a credit card is typically controlled by the bank
issuing the card and displays information,
such as the account number, a three or four-digit authentication code,
validity of the card, name of issuing bank, name
of the interbank network, and the like. The payment instruments also include a
hologram having embedded within
security features and an integrated circuit to support Europay-Mastercard-Visa
("EMV") payment functionalities.
Despite the aforementioned options, the choices for what is to appear on a
payment instrument are limited. When a
new payment instrument is issued to a user, that user is told (usually via a
sticker on the card) to activate the payment
instrument by calling a phone number or by visiting a website where the user
registers the payment instrument by
providing personally identifiable information.
[0003] Business owners often use multiple accounts and multiple payment
instruments for their business.
Accounting for business owners is complicated, in part because of the multiple
payment accounts and payment
instruments. Business owners often invest significant resources into managing
and separating business and personal
funds in a secure and fair manner. Furthermore, cash flow can be challenging
for business owners. For instance,
business owners want quick access to their earned funds (quicker than what is
currently available via traditional
banking methods). Further, business owners do not feel in control of their
finances given conventional business
banking techniques. That is, business owners want a transparent understanding
of their cash flow.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] Features of the present disclosure, its nature and various
advantages, will be more apparent upon
consideration of the following detailed description, taken in conjunction with
the accompanying drawings in which:
[0005] FIG. 1 illustrates an example environment for associating a
payment instrument with an account that is
managed by a payment processing service from POS transactions of a merchant
and enabling the merchant to use
the payment instrument for transactions with other merchants (e.g., business-
to-business transactions), as described
herein.
[0006] FIG. 2 illustrates an example process for associating a payment
instrument with an account of a merchant
during onboarding of a new merchant, as described herein.
[0007] FIG. 3 illustrates an example process for linking a payment
instrument to a stored balance of a merchant
after onboarding of the merchant, as described herein.
[0008] FIG. 4 illustrates an example user interface (UI) from which a
merchant can send a request to link a
payment instrument with a stored balance of the merchant, as described herein.
[0009] FIG. 5 illustrates an example Ul from which a merchant can
personalize their payment instrument, as
described herein.
1
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0010] FIG. 6 illustrates an example process for personalizing a payment
instrument, as described herein.
[0011] FIG. 7 illustrates an example environment for activating a payment
instrument, as described herein.
[0012] FIG. 8 illustrates another example environment for activating a
payment instrument, as described herein.
[0013] FIG. 9 illustrates an example process for activating a payment
instrument, as described herein.
[0014] FIG. 10 illustrates an example environment for tracking the movement
of funds in and out of a stored
balance and enabling a merchant associated with the stored balance to manage
their stored balance, as described
herein.
[0015] FIG. 11 illustrates an example process for presenting a Ul
representative of the ledger (or a portion thereof)
corresponding to its stored balance, as described herein.
[0016] FIG. 12 illustrates an example Ul for presenting at least a portion
of a ledger of a stored balance of a
merchant, as described herein.
[0017] FIG. 13 illustrates an example process for opening a balance
applet responsive to an interaction between
a payment instrument and a payment reader, as described herein.
[0018] FIG. 14 illustrates an example process for classifying
transactions, as described herein.
[0019] FIG. 15 is an example Ul for presenting at least a portion of a
ledger of a stored balance of a merchant,
wherein individual transactions are associated with an indicator as to whether
the transaction is a business expense
or a personal expense, as described herein.
[0020] FIG. 16 illustrates an example process for associating electronic
records with indications of transactions in
a ledger, as described herein.
[0021] FIG. 17 is an example Ul for presenting at least a portion of a
ledger of a stored balance of a merchant,
wherein individual transactions are associated with electronic records of the
individual transactions, as described
herein.
[0022] FIG. 18 illustrates an example process for intelligently managing
authorization requests, as described
herein.
[0023] FIG. 19 depicts an illustrative block diagram illustrating a system
for performing techniques as described
herein.
[0024] In the figures, the left-most digit(s) of a reference number
identifies the figure in which the reference number
first appears. The use of the same reference numbers in different figures
indicates similar or identical items or features.
The drawings are not to scale.
DETAILED DESCRIPTION
[0025] Techniques described herein are directed to an unconventional
business banking product that allows
merchants to store payment revenue securely in an account and utilize a debit
card linked to the account to quickly
access funds in their account. For instance, a payment processing service can
process point-of-sale (POS)
transactions on behalf of a merchant. Funds generated from the POS
transactions can be stored in an account that
is managed by the payment processing service (e.g., not a traditional bank
account). In at least one example, the
payment processing service can manage the account via a ledger.
[0026] The account can be associated with multiple withdrawal channels.
For instance, the merchant can access
the funds in the account by a scheduled deposit from the account to a linked
bank account. In such an example, the
2
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
payment processing service can initiate a deposit (e.g., via ACH, etc.) from
the account managed by the payment
processing service to the bank account at a prearranged time after a POS
transaction is funded. Such scheduled
deposits are often scheduled for the next business day or later.
[0027] Further, the merchant can access the funds in the account by an
instant deposit from the account to a
linked bank account. In such an example, the payment processing service can
initiate a deposit (e.g., via debit rails,
etc.) from the account managed by the payment processing service to the bank
account upon receiving a request from
the merchant. A request for an instant deposit can be made substantially
immediately after a POS transaction is
funded. Instant deposits can often be associated with an additional fee due to
the increased convenience of "on
demand" access to the funds in the account.
[0028] Techniques described herein are directed to yet another way that a
merchant can access funds in the
account: a linked debit card. The linked debit card allows the merchant to
access funds in the account substantially
immediately after a POS transaction is funded. As the funds do not need to be
transferred from the payment
processing service to a bank account, the merchant can have "on demand" access
to their funds without incurring
additional fees. As described herein, the merchant can personalize the debit
card by adding a unique identification
pattern, selecting icons, and adding other flare that is representative of the
merchant and/or their business (e.g., logos,
colors, etc.).
[0029] Further, techniques described herein are directed to a balance
applet enables merchants to check, track,
and use their funds via a single access point (e.g., a POS application on a
POS terminal, a dashboard presented via
a web browser, etc.). The balance applet can enable merchants to check how
much money they are earning (e.g.,
via presentation of available earned balance), understand where their money is
going (e.g., via deposit reports (which
can include a breakdown of fees), spend reports, etc.), access/use earned
money (e.g., via scheduled deposit, instant
deposit, linked payment instrument, etc.), feel in control of their money
(e.g., via management of deposit schedule,
deposit speed, linked instruments, etc.), etc. Furthermore, the balance applet
can enable merchants to visualize their
cash flow to track their financial health, set aside money for upcoming
obligations (e.g., savings), organize money
around goals, etc. Such an applet allows merchants to feel in control of their
finances by providing transparency to
their cash flow and easing access to account management.
[0030] As a non-limiting example, a merchant runs his own shoe repair
business. As the merchant performs shoe
repairs, the merchant is paid for such services via a POS application
executing on a device of the merchant (e.g., a
POS terminal). Funds resulting from such services are deposited into a secure
account that is managed by a payment
processing service. The merchant can use a personalized debit card that is
linked to his account to buy the supplies
he needs for shoe repairs. Additionally, the merchant can check the balance of
the account via the balance applet.
For instance, the merchant can check the balance of the account at the
beginning and end of each day to know where
he stands. Further, the merchant can periodically transfer funds from his
balance to a linked bank account for making
purchases without using the debit card. That is, the merchant can store his
business funds securely in a manner that
he can have instant access (via the personalized debit card) and the merchant
can leverage the balance applet to
monitor his cash flow.
[0031] Techniques described herein are directed to unconventional means
for activating a debit card linked to an
account of a merchant. For instance, the merchant can utilize a payment reader
that is coupled to a POS terminal to
3
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
activate the debit card. In an example, the merchant can tap, dip, swipe, etc.
a debit card in an inactive state via the
payment reader. The payment reader can read payment data from the debit card
and a POS application executing
on the POS terminal can facilitate the confirmation that the payment data
corresponds to the debit card. Accordingly,
the debit card can be activated for use by the merchant.
[0032] Furthermore, techniques described herein are directed to
personalizing the debit card. For instance, as
described herein, a merchant can personalize a pattern (e.g., a signature, a
Quick Response (QR) code, a photograph,
a three-dimensional image, an alphanumeric code, a text, etc.), icons, and
other information that can be associated
with the debit card so that the debit card has a unique presentation
particular to the merchant. In some examples, the
signature, icons, etc. can be printed on a stock material (such as by using a
laser or ink jet printer) or can be otherwise
.. associated with the stock material via silk screening, use of stickers or
labels, embossing, etching, engraving, painting
and the like. Additional details are provided below.
[0033] Techniques described herein are directed to managing the movement
of money through an account of a
merchant. For instance, the balance applet, as described herein, can track
payroll payments from the account (e.g.,
payments to employees of the merchant), payments to other merchants (e.g.,
business-to-business) directly from the
account or from the linked debit card, withdrawals made via scheduled deposit
and/or instant deposit, deposits from
POS transactions, deposits from other bank accounts, etc. The balance applet
as described herein allows merchants
to access information relating to their business banking account via an
integrated platform, which can be accessible
via a user interface (UI) presented via a POS terminal or other merchant
device.
[0034] Furthermore, techniques described herein are directed to
intelligently managing authorization requests. In
an example, when a payment processing service controls a payment instrument,
such as a debit card linked to an
account, and receives an authorization request in association with a
transaction, instead of automatically declining (if
account balance is below the amount of the authorization request), the payment
processing service can approve the
authorization request (and thus, temporarily cover the cost of the
transaction) if the payment processing service
believes that the ultimately charged amount will be less than or equal to the
account balance. Such techniques attempt
to reduce the number of declines experienced by payment instrument users,
thereby decongesting networks
associated with payment processing and increasing bandwidth within the payment
processing network. Additional
details are described below.
[0035] While the aforementioned description is directed to a debit card,
as described below, techniques described
herein can be directed to any type of payment instrument. Furthermore, while
the aforementioned description is
directed to a merchant end user, techniques described herein can apply to any
type of end user. Moreover, for
purposes of this discussion, an "item" can refer to any good or service that
can be purchased or otherwise made
available for acquisition (e.g., purchase, rent, borrow, barter, etc.) from a
merchant.
[0036] FIG. 1 illustrates an example environment 100 for associating a
payment instrument with an account that
is managed by a payment processing service from POS transactions of a merchant
and enabling the merchant to use
the payment instrument for transactions with other merchants (e.g., business-
to-business transactions).
[0037] In an example, a merchant 102 can operate a merchant device 104.
For the purpose of this discussion, a
merchant can be any entity that offers items (e.g., goods or services) for
purchase or other means of acquisition (e.g.,
rent, borrow, barter, etc.). The merchant device 104 can have an instance of a
POS application 106 stored thereon.
4
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
The POS application 106 can configure the merchant device 104 as a POS
terminal, which enables the merchant 102
to perform transactions with one or more customers 108. For the purpose of
this discussion, such transactions can
be referred to as "POS transactions" and/or "transactions." In at least one
example, the POS application 106 can
determine transaction data 110 associated with the POS transactions.
Transaction data 110 can include payment
.. data, which can be obtained from a reader device associated with the
merchant device 104, user authentication data,
purchase amount information, point-of-purchase information (e.g., item(s)
purchased, date of purchase, time of
purchase, etc.), etc. The POS application 106 can send transaction data 110 to
one or more servers 112 of a payment
processing service (or another acquirer, as described below). Furthermore, the
POS application 106 can present a
Ul to enable merchants to interact with the POS application 106 and/or the
payment processing service via the POS
application 106.
[0038] The server(s) 112 can store one or more modules, including, but
not limited to, a merchant module 114, a
set-up module 116, and a balance management module 118. The merchant module
114 can, among other things,
process transactions on behalf of the merchant 102 (and one or more other
merchants). The server(s) 112 can be a
cloud computing environment, a virtualized computing environment, a computer
cluster, or any combination thereof.
[0039] The merchant module 114 can analyze the transaction data to
determine an amount of funds owed to the
merchant 102. Based on determining the amount of funds owed to the merchant
102, the merchant module 114 can
send an indication to the balance management module 116 and can facilitate the
deposit of such funds into an account.
The account can have a stored balance 120, which can be managed by the balance
management module 116. That
is, the stored balance 120 can be an account managed by the payment processing
service. For purposes of this
discussion, "account" and "stored balance" can be used interchangeably to
refer to such an account. The stored
balance 120 is different from a conventional bank account at least because the
stored balance 120 is managed by a
ledger of a payment processing service and the associated funds are accessible
via at least three withdrawal channels:
instant deposit, scheduled deposit, and a linked payment instrument.
[0040] As described above, the merchant 102 can access the funds in the
stored balance 120 by a scheduled
deposit from the stored balance 120 to a linked bank account 122. In such an
example, the server(s) 112 can initiate
a deposit from the stored balance 120 managed by the server(s) 112 to the
linked bank account 122 that is managed
by one or more servers 124 of a bank or other financial institution. The
deposit can occur at a prearranged time after
a POS transaction is funded. Such scheduled deposits are often a next business
day or later. In some examples,
scheduled deposits are a default withdrawal channel associated with stored
balances, such as the stored balance 120.
[0041] Further, the merchant 102 can access the funds in the stored balance
120 by an instant deposit from the
stored balance 120 to a linked bank account 122. In such an example, the
server(s) 112 can initiate a deposit from
the stored balance 120 to the linked bank account 122 upon receiving a request
from the merchant 102. A request
for an instant deposit can be made substantially immediately after a POS
transaction is funded. Instant deposits can
often be associated with an additional fee due to the increased convenience of
"on demand" access to the funds in
the stored balance 120.
[0042] Additionally, the merchant 102 can access funds in the stored
balance 120 via a payment instrument 126
that is linked to the stored balance 120. For the purpose of this discussion,
a payment instrument can be "linked" such
5
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
that payment data of the payment instrument can be mapped, or otherwise
associated with, a stored balance. The
payment instrument 126 can have an available balance (e.g., value) that
corresponds to the stored balance 120.
[0043] The payment instrument 126 can be designed according to a
specification corresponding to, for example,
a debit card, a credit card, a smart-card (conforming to a payment instrument
technical standard, such as a Europay-
MasterCard-Visa (EMV") standard), a radio frequency identification tag (i.e.,
near field communication enabled
object), a biometric payment instrument, a virtual payment card stored on a
device such as a smart phone and
transmittable, for example, via near field communication ("NFC"), and can
include personally identifiable information
(PII"), such as merchant name, account number, and the like. In an example,
the payment instrument 126 can be a
software instrument or virtual instrument which can be stored in a virtual
wallet configured to initiate contactless
payment transactions, e.g., a key fob, a mobile device having an RFID tag,
etc. In general, the payment instrument
126 can be any kind of financial instrument that holds financial value or
provides a promise to pay at a later time.
[0044] As described above, the merchant 102 can personalize the payment
instrument 126. For instance, the
payment instrument 126 can have embedded within, or displayed on a surface, a
unique pattern corresponding to or
provided by the merchant. The unique pattern, for example, can be a signature,
a QR code, a photograph, a three-
dimensional image, an alphanumeric code, a text, or any other pattern. The
unique pattern can further comprise a
placement of a signature, a QR code, a photograph, a three-dimensional image,
an alphanumeric code, a text, or any
other pattern on the payment instrument, for instance, relative to a chip on
the payment instrument and the number of
the payment instrument. Furthermore, the merchant 102 can personalize the
payment instrument 126 by selecting
icons and adding other flare that is representative of the merchant 102 and/or
their business. For instance, as a non-
limiting example, the merchant 102 can operate a coffee shop and thus can
personalize the payment instrument 126
with an icon of a coffee cup. The set-up module 116 can facilitate such
personalization, as described below.
[0045] The merchant 102 can use the payment instrument 126 to transact
with other merchants 128, for instance
via business-to-business ("B2B") transactions. That is, the merchant 102 can
purchase item(s) (e.g., goods or
services) from another merchant 128 and can pay for the item(s) using the
payment instrument 126. The merchant
102 can use the payment instrument 126 in card present and card-not-present
("CNP") transactions (e.g., payment
data associated with the payment instrument 126 is used for a transaction but
the payment instrument 126 is not
physically present). The balance management module 118 can receive an
indication of a purchase using the payment
instrument 126 and can debit an amount of the purchase from the stored balance
120. The balance management
module 118 can also credit the stored balance 120 based on POS transactions,
as described above, and can debit
the stored balance 120 based on other payments such as payroll payments to
employees, direct transfers to vendors
for inventory items, scheduled and/or instant deposits, etc. Additional
details associated with the ledger and the
balance management module 118 are described below.
[0046] In addition to the withdrawal channels described above, funds can
be withdrawn or deducted from the
stored balance 120 to pay for processing fees, capital loan repayment,
subscriptions, savings, bill pay, etc. That is,
while three withdrawal channels are described above; funds can be withdrawn
from the stored balance 120 via
additional or alternative other withdrawal channels.
[0047] FIG. 2 illustrates an example process 200 for associating a
payment instrument with an account of a
merchant during onboarding of a new merchant.
6
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0048] For the purpose of this discussion, onboarding can refer to
registering a potential merchant with a service
provider, such as a payment processing service provider (the "payment
processing service"). In some examples,
onboarding can involve presenting various questions, prompts, and the like to
a potential merchant to obtain merchant
information that can be used to generate a merchant profile for the potential
merchant. Responsive to the potential
merchant providing all necessary merchant information, the potential merchant
can be onboarded to the payment
processing service as a merchant, such as the merchant 102. In some examples,
the merchant 102 can opt-in to
using a payment instrument and personalizing the payment instrument during
onboarding.
[0049] Block 202 illustrates, during an onboarding process of a new
merchant, presenting a Ul indicating that
funds of the new merchant are stored in a stored balance that is accessible by
a payment instrument. In at least one
example, during an onboarding process, the set-up module 116 can cause a Ul to
be presented to the merchant 102
informing the merchant 102 that funds resulting from POS transactions
processed by the payment processing service
are securely stored in a stored balance 120. The Ul can additionally inform
the merchant 102 that the funds are
available to the merchant 102 substantially immediately after funding a POS
transaction via a payment instrument that
can be linked to the stored balance 120. In at least one example, the Ul can
be presented via a web browser, or the
like. In other examples, the Ul can be presented via an application, such as a
mobile application or desktop application,
which is provided by the payment processing service, or which can be an
otherwise dedicated application. For
instance, the Ul can be presented via the POS application 106.
[0050] Block 204 illustrates determining whether the merchant opts-in to
linking the payment instrument to the
stored balance. In at least one example, the merchant 102 can interact with
the Ul to indicate whether the merchant
102 opts-in to linking the payment instrument to the stored balance 120. For
instance, the merchant 102 can select a
selectable control (e.g., software or hardware button, etc.) to indicate that
the merchant 102 opts-in to linking the
payment instrument to the stored balance 120. Or, the merchant 102 can provide
another indication that the merchant
102 opts-in to linking the payment instrument to the stored balance 120. In
some examples, the payment instrument
can be provided to the merchant 102 without the merchant 102 expressly opting-
in to linking the payment instrument
(e.g., the payment instrument can be a default option). In other examples, the
merchant 102 can interact with the Ul
indicating that the merchant 102 opts-out of linking the payment instrument to
the stored balance 120. For instance,
the merchant 102 can select a selectable control associated with linking a
bank account to the stored balance 120
thereby impliedly opting-out of linking the payment instrument to the stored
balance 120.
[0051] Block 206 illustrates receiving a request to link the payment
instrument to the stored balance. Responsive
to the merchant 102 opting-in to linking the payment instrument, the set-up
module 116 can receive a request to link
the payment instrument to the stored balance. In at least one example, the
request can be associated with merchant
data such as a personal name, an address, a date of birth, a personal
identifier (e.g., social security number) as
received by the merchant 102 during onboarding.
[0052] Block 208 illustrates presenting a Ul to enable the merchant to
personalize the payment instrument.
Responsive to receiving the request to link the payment instrument to the
stored balance, the set-up module 116 can
cause a Ul to be presented to enable the merchant 102 to personalize the
payment instrument. That is, the set-up
module 116 can send instructions to the merchant device 104 to present the Ul
via a display of the merchant device
104. In at least one example, the Ul can be presented via a web browser, or
the like. In other examples, the Ul can
7
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
be presented via an application, such as a mobile application or desktop
application, which is provided by the payment
processing service, or which can be an otherwise dedicated application. For
instance, the Ul can be presented via
the POS application 106.
[0053] The merchant 102 can personalize the payment instrument 126 via
interaction with the Ul. For instance,
.. the payment instrument 126 can have embedded within, or displayed on a
surface, a unique pattern corresponding to
or provided by the merchant 102. The unique pattern, for example, can be a
signature, a QR code, a photograph, a
three-dimensional image, an alphanumeric code, a text, or any other pattern.
The unique pattern can further comprise
a placement of a signature, a QR code, a photograph, a three-dimensional
image, an alphanumeric code, a text, or
any other pattern on the payment instrument, for instance, relative to a chip
on the payment instrument and the number
.. of the payment instrument. Furthermore, the merchant 102 can personalize
the payment instrument 126 by selecting
icons and adding other flare that is representative of the merchant 102 and/or
their business. The set-up module 116
can cause a Ul to be presented to enable the merchant 102 to provide the
unique pattern, select icon(s), etc. Additional
details are provided below.
[0054] Block 210 illustrates prompting the merchant to link a bank
account of the merchant to a merchant profile.
.. If the merchant 102 does not opt-in to using the payment instrument, the
set-up module 116 can prompt the merchant
102 to link a bank account of the merchant 102 to a merchant profile of the
merchant 102. For instance, the set-up
module 116 can send instructions to the merchant device 104 to cause a Ul to
be presented to the merchant 102,
prompting the merchant 102 to input bank account data. In at least one
example, the Ul can be presented via a web
browser, or the like. In other examples, the Ul can be presented via an
application, such as a mobile application or
desktop application, which is provided by the payment processing service, or
which can be an otherwise dedicated
application. For instance, the Ul can be presented via the POS application
106.
[0055] Block 212 illustrates receiving bank account data associated with
the bank account of the merchant. The
merchant 102 can input bank account data responsive to the prompt. The
merchant 102 can provide at least a name
of a bank, an account number, a routing number, etc. so that the merchant
module 114 can deposit funds into the
.. bank account 122 of the merchant 102.
[0056] Block 214 illustrates associating the bank account of the merchant
with the merchant profile. Responsive
to receiving the bank account data, the set-up module 116 can associate the
bank account with a profile of the
merchant 102, to which the stored balance 120 is also linked. The merchant
module 114 can facilitate the deposit of
funds from the stored balance 120 into the linked bank account for instance,
via scheduled deposits, instant deposits,
etc.
[0057] While FIG. 2 illustrates a process for linking a payment
instrument 126 to a stored balance 120 of a
merchant 102 during onboarding, in some examples, a merchant 102 may not link
a payment instrument 126 during
onboarding (e.g., the merchant 102 opted out, the linked payment instrument
was not available, etc.). In such
examples, the merchant 102 can link a payment instrument 126 to their stored
balance 120 at a time after onboarding.
[0058] FIG. 3 illustrates an example process 300 for linking a payment
instrument to a stored balance of a
merchant after onboarding. In such an example, the stored balance 120 can be
accessible to the merchant 102 via
scheduled deposits, instant deposits, etc. That is, the merchant 102
previously provided bank account information for
linking their bank account to a merchant profile of the merchant 102. In such
an example, until a payment instrument
8
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
is linked to the stored balance 102 (and activated), the merchant module 114
can facilitate the deposit of funds from
the stored balance 120 into the linked bank account for instance, via
scheduled deposits, instant deposits, etc.
[0059] Block 302 illustrates presenting an offer to link a payment
instrument with a stored balance of a merchant,
the stored balance being maintained in a ledger of a payment processing
service. In at least one example, the set-up
module 116 can send an offer to link a payment instrument with a stored
balance to a device of a merchant. For
instance, the set-up module 116 can send an email, text message, push
notification, etc. to the merchant device 104.
The offer can explain details associated with linking a payment instrument to
the stored balance 120 and can include
a selectable control that enables the merchant 102 to initiate a request to
link the payment instrument to the stored
balance 120. In another example, the set-up module 116 can cause a selectable
control to be presented via a
dashboard presented via a webpage, the POS application 106, etc. For the
purpose of this discussion, a dashboard
can be a Ul that provides an at-a-glance view of key information (e.g.,
associated with transactions, payments, etc.).
Selection of the selectable control can initiate a request to link the payment
instrument to the stored balance 120. In
additional or alternative examples, another mechanism can be used to enable a
merchant to indicate acceptance (or
not) of the offer.
[0060] Block 304 illustrates determining whether the merchant accepts the
offer. The set-up module 116 can
receive an indication that the merchant 102 accepts the offer (e.g., by
selection of a selectable control presented via
an email, text message, push notification, dashboard, etc.). Block 306
illustrates receiving a request to link the
payment instrument to the stored balance. Responsive to the merchant 102
opting-in to linking the payment instrument
(e.g., accepting the offer), the set-up module 116 can receive a request to
link the payment instrument to the stored
balance.
[0061] Block 308 illustrates presenting a Ul to enable the merchant to
personalize the payment instrument.
Responsive to receiving the request to link the payment instrument to the
stored balance, the set-up module 116 can
cause a Ul to be presented to enable the merchant 102 to personalize the
payment instrument. That is, the set-up
module 116 can send instructions to the merchant device 104 to present the Ul
via a display of the merchant device
104. In at least one example, the Ul can be presented via a web browser, or
the like. In other examples, the Ul can
be presented via an application, such as a mobile application or desktop
application, which is provided by the payment
processing service, or which can be an otherwise dedicated application. For
instance, the Ul can be presented via
the POS application 106. The merchant 102 can personalize the payment
instrument 126 via interaction with the Ul,
as described above.
[0062] Block 310 illustrates continuing to enable access to the stored
balance via scheduled deposits and/or
instant deposits. If the merchant 102 does not accept the offer, the merchant
module 114 can continue to enable
access to the stored balance 120 via scheduled deposits and/or instant
deposits to the linked bank account.
[0063] In some examples, the merchant 102 can initiate a request to link
the payment instrument with the stored
balance (e.g., without first having received an offer), as illustrated in
block 312.
[0064] In at least one example, as part of the ordering process¨which can
be associated with onboarding or at a
later time as described above¨the merchant 102 can input and/or confirm
merchant information including, but not
limited to, a shipping address (indicating where to ship the payment
instrument 126), an account owner (e.g., which
can be associated with the payment instrument 126), a business name (e.g.,
which can be associated with the payment
9
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
instrument 126 and/or can appear on receipts and customer statements), a date
of birth, a zip code, etc. Furthermore,
in some examples, responsive to completing the ordering process (and prior to
receipt and/or activation of the payment
instrument 126), the merchant 102 can utilize the payment data associated with
the payment instrument 126 to perform
CNP transactions. That is, upon completion of the personalization process, the
set-up module 116 can cause a Ul to
be presented that provides the merchant 102 with the payment data, or a
portion thereof, and the merchant 102 can
use the payment data for CNP transactions. In some examples, the merchant 102
cannot use the payment instrument
126 for CNP transactions until after the payment instrument 126 is activated.
[0065] FIGS. 4 and 5 illustrate non-limiting examples of Uls that can be
presented consistent with techniques
described herein. In at least one example, the Ul can be presented via a web
browser, or the like. In other examples,
the Ul can be presented via an application, such as a mobile application or
desktop application, which is provided by
the payment processing service, or which can be an otherwise dedicated
application. For instance, the Ul can be
presented via the POS application 106. It should be noted that the Uls
described can present additional or alternative
content in additional or alternative configurations.
[0066] FIG. 4 illustrates an example Ul 400 from which a merchant can
send a request to link a payment instrument
with a stored balance of the merchant. As described above, in an example, the
set-up module 116 can cause a
selectable control 402 to be presented via a dashboard 404 presented via a
webpage, the POS application 106, etc.
In some examples, the selectable control 402 can be presented in association
with an offer. Selection of the selectable
control 402 can initiate a request to link the payment instrument to the
stored balance 120. In some examples, the Ul
400 can include a selectable control 406 to enable the merchant 102 to
initiate a transfer of funds (e.g., via an instant
or scheduled deposit) to the merchant's bank account 122. Additional details
associated with the Ul 404 are described
below.
[0067] As described above, the merchant 102 can personalize the payment
instrument 126. For instance, the
payment instrument 126 can have embedded within, or displayed on a surface, a
unique pattern corresponding to or
provided by the merchant 102. The unique pattern, for example, can be a
signature, a QR code, a photograph, a three-
dimensional image, an alphanumeric code, a text, or any other pattern. The
unique pattern can further comprise a
placement of a signature, a QR code, a photograph, a three-dimensional image,
an alphanumeric code, a text, or any
other pattern on the payment instrument, for instance, relative to a chip on
the payment instrument and the number of
the payment instrument.
[0068] Furthermore, the merchant 102 can personalize the payment
instrument 126 by selecting icons and adding
other flare that is representative of the merchant 102 and/or their business.
The set-up module 116 can cause a Ul to
be presented to enable the merchant 102 to provide the unique pattern, select
icon(s), etc. FIG. 5 illustrates an
example Ul 500 from which a merchant can personalize their payment instrument.
[0069] As illustrated in FIG. 5, the merchant 102 can provide a unique
pattern via an interaction with the Ul 500,
for instance, by signing in a signature box 502 presented via the Ul 500. In
such an example, the merchant 102 selects
or provides a signature and the POS application 106, for example, can send the
signature to the set-up module 116.
The set-up module 116 receives the signature and converts and/or encrypts the
signature into a pattern, which is
capable of being imprinted, embedded or otherwise associated with the payment
instrument.
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0070] In some examples, the Ul 500 can present push notifications or
messages to the merchant 102, such as
"system is ready to accept your signature. Do you want a select an image as a
signature or provide your own?" with
attached actions (e.g., "Yes, provide me options" to show pre-selection
options for the merchant to select, or "Provide
my own") for providing a custom signature which can be an image or text or a
combination of both, and so on.
[0071] As used herein, the term "unique pattern" is a unique identifier
that can either be provided by a merchant
by keying in their preferred unique pattern on a merchant Ul, such as touch
screen or keypad or by selecting from
amongst a list of options generated by the server(s) 112 (e.g., the set-up
module 116). In another example, the set-up
module 116 can automatically and/or randomly assign a unique pattern to the
merchant 102 at the time of account
creation. As described above, the unique pattern can be a signature,
alphanumeric text, a shape, an image, a barcode,
a QR code, a radio frequency identifier (RFID) tag, and so on.
[0072] The unique pattern is referenced as being associated with or
printed on the payment instrument, however,
the unique pattern can be provided with the payment instrument, for example in
an accompanying letter. The unique
pattern can also be embedded, such that it is hidden to naked eye. The unique
pattern once encrypted and printed or
associated to the payment instrument can be mentioned as pattern in the
specification. The unique pattern can also
be an analog of a digital file that comprises a picture or a drawing that is
in a JPEG or other file format.
[0073] Further, the merchant 102 can select one or more icons 502 via
interaction with the Ul 500. In an example,
a merchant 102 can provide a touch input to select an icon corresponding to a
position of the touch input. In some
examples, the icon(s) 502 can be arranged in an order based on a
characteristic of the merchant 102, as described
below with reference to FIG. 6. In an example, the merchant 102 selects an
icon and the POS application 106, for
example, can send the selected icon, or an indication of such, to the set-up
module 116. The set-up module 116
receives the icon, or the indication of such, and converts and/or encrypts the
icon into an icon which is capable of
being imprinted, embedded or otherwise associated with the payment instrument.
[0074] The icon(s) 502 are referenced as being associated with or printed
on the payment instrument; however,
the icon(s) 502 can be provided with the payment instrument, for example in an
accompanying letter. The icon(s) 502
can also be embedded, such that they are hidden to naked eye. The icon(s) 502
once encrypted and printed or
associated to the payment instrument can be mentioned as pattern in the
specification. An icon can also be an analog
of a digital file that comprises a picture or a drawing that is in a JPEG or
other file format.
[0075] It should be noted that in some examples, the unique pattern
and/or selected icon(s) can be reviewed
manually or by an automated system to determine whether the unique pattern
and/or selected icon(s) are compliant
with terms of service or other standards imposed by the payment processing
service. In an example where a unique
pattern and/or selected icon(s) are rejected, the merchant 102 can be notified
and can be presented with a Ul to enable
the merchant 102 to reorder a payment instrument that complies with the terms
of service or other standards.
[0076] In FIG. 5, a non-limiting example of a personalized payment
instrument 126 is provided.
[0077] A variety of materials can be used to craft the payment instrument
126. For example, the payment
instrument 126 can be crafted of stock materials, such as plastics, paper,
laminates, and the like. According to the
stock material used to construct the payment instrument 126, a number of
techniques can be used to associate the
unique pattern and/or icon(s) with the payment instrument 126. For instance,
the unique pattern and/or icon(s) can be
printed on the stock material (such as by using a laser or ink jet printer).
Other examples include silk screening, use
11
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
of stickers or labels, embossing, etching, engraving, painting and the like.
In some cases, the stock material can have
some information already included, such as a company logo, legal notices, and
the like, or this information can be
placed onto the stock material at the time the unique pattern and/or icon(s)
are placed onto the stock material.
[0078] In addition to providing the unique pattern and/or icon(s) on the
payment instrument 126, some or all of the
.. unique pattern and/or icon(s) can be placed in portions, for example a
first portion on one side and the second portion
on the other side of the payment instrument 126. The activation then involves
reading the image in two parts and in a
specific order. The unique pattern and/or icon(s) can also be printed onto
other materials as well. For example, the
unique pattern and/or icon(s) can be provided on any inserts mailed with the
payment instrument 126, the envelope
or mailer, and the like.
[0079] A wide variety of techniques can be used to deliver the payment
instrument 126 to the merchant 102 after
it has been created. For example, the payment instrument 126 could be attached
to a card carrier and placed into a
mailer along with any other inserts. This can then be mailed to the merchant
102. Other techniques include personal
delivery, by courier services, by in-store pick-up and the like. The payment
instrument 126 can also be produced at a
location of the merchant 102 (e.g., a brick and mortar).
[0080] As described herein, the payment instrument 126 can be in an
inactive state until activated by the merchant
102. In this way, if the payment instrument 126 is intercepted or stolen
before reaching the merchant 102, it may not
be used. One way to activate the payment instrument 126 is to require certain
information to be supplied to the payment
processing service (or other authentication service) by the merchant 102. This
information can be input by the
merchant 102 and then transmitted to the payment processing service (or other
authentication service), such as bye-
mail, by a phone call, by a separate mailing, or the like. Instead of
expecting the merchant 102 to provide his or her
phone number to activate the account and then calling, the payment instrument
126 described herein can include the
unique pattern and/or icon(s) having activation capabilities. The unique
pattern and/or icon(s) can trigger the activation
process without the merchant 102 having to reach out to a representative of
the payment processing service. As such,
the process of activation is not just automated but also initiated by a
feature on the payment instrument 126 that is
.. otherwise inactive and merely ornamental and design related. Additional
details associated with activating the
payment instrument 126 are described below.
[0081] FIG. 6 illustrates an example process 600 for personalizing a
payment instrument.
[0082] Block 602 illustrates receiving a request to link a payment
instrument with a stored balance of a merchant
that is maintained by a payment processing service. In at least one example,
the set-up module 116 can receive a
.. request to link a payment instrument with the stored balance 120 of the
merchant 102. In some examples, the set-up
module 116 can receive the request during onboarding of the merchant,
responsive to an offer from the payment
processing service, etc., as described above.
[0083] Block 604 illustrates determining characteristic(s) of the
merchant. In at least one example, the set-up
module 116 can determine characteristic(s) of the merchant 102. As described
above, the merchant 102 can be
associated with a merchant profile, that can be stored in a database
associated with the server(s) 112. In at least one
example, the merchant profile can store information associated with the
merchant 102. For instance, the merchant
profile can store merchant data including, but not limited to, a merchant
category classification ("MCC"), item(s) offered
for sale by the merchant, transaction data associated with transactions
conducted by the merchant (e.g., via the POS
12
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
application 106), hardware (e.g., device type) used by the merchant, previous
loans made to the merchant, previous
defaults on said loans, an indication of risk (e.g., based at least in part on
fraud, chargeback, etc.) associated with the
merchant, etc. The merchant profile can securely store bank account
information as provided by the merchant.
Further, the merchant profile can store payment data associated with a payment
instrument linked to a stored balance
120 of the merchant 102, and data associated with the stored balance 120. In
such an example, the set-up module
116 can access a profile associated with the merchant 102 to determine the
characteristic(s).
[0084] If a merchant is new merchant (e.g., onboarding), the set-up
module 116 can access merchant data as
input from the merchant during onboarding. For instance, such a merchant can
input an MCC, an address, inventory
item(s), etc.
[0085] Block 606 illustrates accessing icon(s) for personalizing the
payment instrument. In at least one example,
the server(s) 112 can store a database of icon(s) that can be used for
personalizing the payment instrument. In an
additional or alternative example, a merchant can upload or otherwise provide
icon(s) for personalizing the payment
instrument. Further, in some examples, the set-up module 116 can access
icon(s) via third-party service provider(s).
[0086] Block 608 illustrates arranging the icon(s) based on the
characteristic(s) of the merchant. In at least one
example, the set-up module 116 can determine an order for presenting the
icon(s) based on the characteristic(s) of
the merchant 102. For instance, the set-up module 116 can determine that a
first icon that is more relevant to the
merchant 102, as determined by the characteristic(s) of the merchant 102,
should be presented to the merchant 102
prior to a second icon that is less relevant to the merchant 102. As a non-
limiting example, if the merchant is a coffee
café, the set-up module 116 can prioritize icons related to coffee and/or
cafés over icons that are related to home
repair services or retail services.
[0087] Block 610 illustrates presenting the icon(s) via a Ul. The set-up
module 116 can cause the icon(s) to be
presented via a Ul. A non-limiting example of such a Ul is provided above with
reference to FIG. 5. By intelligently
ordering icons, techniques described herein enable improved user interaction
with the Ul. That is, the merchant 102
does not need to sort through various irrelevant icons and, instead, can view
icon(s) that are most relevant to the
-- merchant 102 prior to viewing icon(s) that are less relevant to the
merchant 102.
[0088] Block 612 illustrates receiving a selection of at least one icon.
As described above, the set-up module 116
can receive an indication of a selection of at least one icon. For instance,
the merchant 102 can interact with the Ul
(e.g., touch input, spoken input, click, etc.) to select one or more of the
icons and the POS application 106 can send
an indication of such selections to the set-up module 116.
[0089] Block 614 illustrates sending an instruction to associate at least
one icon with the payment instrument.
Responsive to receiving the indication of the selection, the set-up module 116
can generate an instruction associated
with the configuration of the payment instrument. The set-up module 116 can
send the instruction to a computing
device, which can execute the instructions and generate the personalized
payment instrument. A non-limiting example
of a payment instrument 126 is provided above with reference to FIG. 5. As
described above with reference to FIG. 5,
a number of techniques can be used to associate the icon(s) with the payment
instrument 126. For instance, the icon(s)
can be printed on the stock material (such as by using a laser or ink jet
printer). Other examples include silk screening,
use of stickers or labels, embossing, etching, engraving, painting and the
like.
13
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0090] Once the payment instrument 126 is delivered to the merchant 102,
the merchant 102 initiates a process
to activate the payment instrument 126. For this, a mobile device, for example
the merchant device 104, can execute
a self-guiding tool or provide a personalized flow to walk the merchant 102
through the steps of activating the payment
instrument 126. The merchant 102 can select or provide information in response
to queries that are tailored to the
merchant 102. For example, one of the steps can direct the merchant 102 to
take an image or a portion of the image
of the pattern on the payment instrument 126 through a sensor, such as a
camera, of the merchant device 104. The
merchant device 104, an application executing thereon (e.g., the POS
application 106), or the payment processing
service (e.g., the server(s) 112) that receives the image, then decrypts and
compares the image with unique patterns
stored at the time of registration. If a stored pattern matches the captured
image, the payment processing service can
authorize the payment instrument 126 to be used for purchases, as described
above. However, if the captured image
does not match a stored pattern, the payment instrument 126 is not activated,
as there is an increased likelihood that
the authorization attempt is fraudulent.
[0091] Additionally, in at least one example, the merchant 102 can
utilize a payment reader that is coupled to the
merchant device 104 to activate the payment instrument 126. In an example, the
merchant 102 can insert the payment
instrument 126, which is in an inactive state, into the payment reader.
Additionally or alternatively, the merchant 102
can dip or tap the payment instrument 126 to the payment reader to activate
the payment instrument 126. The payment
reader can read payment data from the payment instrument 126 and the POS
application 106 can facilitate the
confirmation that the payment data corresponds to the payment instrument 126
and activation of the payment
instrument 126. Accordingly, the payment instrument 126 can be activated for
use by the merchant 102. FIGS. 7-9
are directed to such activation techniques. In the context of payment
instruments, the word "activate" can mean: (a)
confirming that the merchant in possession of the payment instrument is the
intended merchant; (b) confirming that
the payment instrument has been securely received by the intended merchant;
(c) registering the payment instrument
with the payment processing service so that the intended merchant can use the
payment instrument towards financial
transactions; (d) associating the payment instrument with the identity of the
merchant through a registration process;
(e) enabling security measures and providing financial protection to the
merchant from the time the payment instrument
is activated; and/or (f) agreeing to the terms and conditions of the payment
processing service or any other entity
issuing the payment instrument.
[0092] FIGS. 7 and 8 illustrate two example environments 700 and 800,
respectively, for activating a payment
instrument.
[0093] FIGS. 7 and 8 include various components of the environment 100, as
described above with respect to
FIG. 1. Some components of the environment 100 are omitted for clarity. In
FIGS. 7 and 8, the server(s) 112
additionally include an activation module 702. The activation module 702 can,
among other things, perform one or
more functions to activate the payment instrument 126.
[0094] Additionally, in FIGS. 7 and 8, a payment reader 704 is depicted
as part of the environments 700 and 800.
The payment reader 704 can physically interact with payment instruments such
as magnetic stripe payment cards,
EMV payment cards, and short-range communication (e.g., near field
communication ("NFC"), radio frequency
identification ("RFID"), Bluetooth , Bluetooth low energy ("BLE"), etc.)
payment instruments. In some examples, the
payment reader 704 can plug in to a port in the merchant device 104, such as a
microphone/headphone port, a data
14
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
port, or other suitable port. The payment reader 704 can be a portable
magnetic stripe card reader, optical scanner,
smartcard (card with an embedded IC chip) reader (e.g., an EMV-compliant card
reader or short-range communication
enabled reader), RFID reader, or the like, configured to detect and obtain
data off any payment instrument.
Accordingly, the payment reader 704 can include hardware implementation, such
as slots, magnetic tracks, and rails
with one or more sensors or electrical contacts to facilitate detection and
acceptance of a payment instrument 126. In
FIGS. 7 and 8, the payment reader 704 is illustrated as being integrated in a
customer-facing device that is coupled
to the merchant device 104. It should be noted, however, that any payment
reader that is capable of reading payment
data from a payment instrument can be used. That is, in additional or
alternative examples, the payment reader 704
can be integrated into the merchant device 104, connectable to the merchant
device 104, etc.
[0095] In at least one example, the merchant 102 can interact with a Ul 706
for activating the payment instrument
126. In at least one example, the Ul 706 can be presented via a web browser,
or the like. In other examples, the Ul
706 can be presented via an application (e.g., mobile or desktop) or applet,
which is provided by the payment
processing service, or which can be an otherwise dedicated application or
applet. For instance, the Ul 706 can be
presented via the POS application 106 or an applet (e.g., a balance applet,
described below) associated with the POS
application 106. In some examples, the merchant 102 can log in to their
payment processing service account (e.g.,
which corresponds to a merchant profile of the merchant 102) via the POS
application 106 to access the Ul 706. In
at least one example, the Ul 706 can include a selectable control that when
selected initiates an activation process.
In some examples, the selectable control can be made available via a status
check of an ordered payment instrument.
That is, the merchant 102 can interact with the Ul 706 to check the status of
their ordered payment instrument 126
and, when the payment instrument 126 is ready for activation, the selectable
control can be availed to the merchant
102. The merchant 102 can indicate a desire to activate the payment instrument
126, for instance via selection of the
selectable control. In another example, the merchant 102 can provide a voice
input indicating that the merchant 102
desires to activate the payment instrument 126.
[0096] In at least one example, the POS application 106 can prompt (e.g.,
via the Ul 706) the merchant 102 to
cause an interaction (e.g., a dip, tap, or swipe) between the payment
instrument 126 and the payment reader 704.
The merchant 102 can cause the payment instrument 126 to interact with the
payment reader 704. Responsive to
such an interaction, the payment reader 704 can read payment data 708 from the
payment instrument 126. The
payment data 708 can include, but is not limited to, a name of the merchant
102, an address of the merchant 102, a
type (e.g., credit, debit, etc.) of a payment instrument 126 from which the
payment data is accessed, a number
associated with the payment instrument 126, a verification value (e.g., PIN
Verification Key Indicator ("PVKI"), PIN
Verification Value ("PVV"), Card Verification Value ("CVV"), Card Verification
Code ("CVC"), etc.) associated with the
payment instrument 126, an expiration date associated with the payment
instrument 126, a primary account number
("PAN") corresponding to the merchant 102 (which can or may not match the
number associated with the payment
instrument 126), restrictions on what types of charges/debts can be made, etc.
In some examples, the payment data
708 can be encrypted. The POS application 106 can send the payment data 708 to
the activation module 702.
[0097] In at least one example, as illustrated in FIG. 7, the activation
module 702 can receive payment data 708
from the POS application 106 and can compare the payment data 708 to known
payment data 710 associated with
the payment instrument 126 provided to the merchant 126. Known payment data
710 can include, but is not limited
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
to, a name of the merchant 102, an address of the merchant 102, a type (e.g.,
credit, debit, etc.) of a payment
instrument 126 from which the payment data is accessed, a number associated
with the payment instrument 126, a
verification value (e.g., PVKI, PW, OW, CVC, etc.) associated with the payment
instrument 126, an expiration date
associated with the payment instrument 126, a PAN corresponding to the
merchant 102 (which can or may not match
the number associated with the payment instrument 126), restrictions on what
types of charges/debts can be made,
etc. In some examples, the known payment data 710 can be stored in the
activation module 702.
[0098] Upon determining that the payment data 708 matches, or otherwise
corresponds to, at least a portion of
the known payment data 710, the activation module 702 can send an activation
notification 712 to the POS application
106. The activation notification 712 can provide a notification to the
merchant 102 that the payment instrument 126 is
activated. In at least one example, the activation notification 712 can be
presented via the Ul 706. In some examples,
responsive to activating the payment instrument 126, the activation module 702
can modify the default withdrawal
channel associated with the stored balance 120. For example, in some
instances, until a payment instrument is linked
to a stored balance, scheduled deposits can be the default withdrawal channel.
However, upon activation of a payment
instrument, the activation module 702 can change the default withdrawal
channel to the payment instrument, thereby
allowing the stored balance 120 to increase. In such an example, the
activation module 702 can send an indication
to the merchant module 114 and/or the balance management module 118 to
temporarily freeze or deactivate
scheduled or instant deposits. Accordingly, funds from POS transactions can be
stored in the stored balance 120
instead of being deposited into a linked bank account of the merchant 102 per
a predetermined schedule (e.g., so the
stored balance 120 has funds to be spent via use of the payment instrument
126). In at least one example, the
activation module 702 can send a notification to the POS application 106 to
notify the merchant 102 of this modification.
Such a notification can be presented via the Ul 706. In some examples, such a
notification can be sent with the
activation notification.
[0099] In an alternative example, as illustrated in FIG. 8, the
activation module 702 can provide the known payment
data 710 to the POS application 106, for example, at some time prior to
activation of the payment instrument 126. In
such an example, the POS application 106 can temporarily store the known
payment data 710. As described above,
the merchant 102 can interact with the Ul 706 or otherwise indicate a desire
to activate the payment instrument 126.
The POS application 106 can prompt the merchant 102 to cause an interaction
(e.g., a dip, tap, or swipe) between the
payment instrument 126 and the payment reader 704. The merchant 102 can cause
the payment instrument 126 to
interact with the payment reader 704. Responsive to such an interaction, the
payment reader 704 can read payment
data 708 from the payment instrument 126. The POS application 106 can compare
the payment data 708 to the
known payment data 710. Upon determining that the payment data 708 matches, or
otherwise corresponds to, at
least a portion of the known payment data 710, the POS application 106 can
send an activation notification 802 to the
activation module 702. The activation notification 802 can provide a
notification to the activation module 702 that the
payment instrument 126 is activated. In some examples, responsive to receiving
the activation notification 802, the
activation module 702 can indicate such and can modify the default withdrawal
channel associated with the stored
balance 120. In at least one example, the activation module 702 can send a
notification to the POS application 106
to notify the merchant 102 of this modification. Such a notification can be
presented via the Ul 706.
16
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0100] While unconventional techniques directed to swipe (or dip, tap) to
activate are described above, the
payment instrument 126 can be activated in more traditional ways as described
above. Additionally or alternatively,
the merchant 102 can log into their payment processing service account via the
POS application 106, enter one or
more data items of the payment data associated with the payment instrument 126
(e.g., a verification value (e.g., PVKI,
PW, CVV, CVC, etc.) associated with the payment instrument 126, an expiration
date associated with the payment
instrument 126, a PAN corresponding to the merchant 102) to activate the
payment instrument 126. Other means for
activating the payment instrument 126 are described above.
[0101] In at least one example, the activation module 702 can facilitate
a two-factor authentication (TFA") process
whereby, prior to activating the payment instrument 126, the activation module
702 can send a communication (e.g.,
a text message, an email, a push notification, etc.) to an address (e.g.,
phone number, email address, etc.) associated
with the merchant profile corresponding to the merchant 102 to verify that the
authorized user (e.g., the merchant 102)
agrees to activate the payment instrument 126. In at least one example, the
communication can include a code or
other identifier. In such an example, the activation module 702 can refrain
from activating the payment instrument 126
until the merchant 102 replies to the communication, for instance by providing
the code or other identifier provided via
the communication. In some examples, the merchant 102 can provide the code or
other identifier via the Ul 706. The
POS application 106 can send the code or other identifier to the activation
module 702, and so long as the code or
other identifier provided corresponds to the code or other identifier sent in
the communication, the activation module
702 can activate the payment instrument 126.
[0102] In some examples, responsive to activating the payment instrument,
the Ul 706 can present a prompt for
the merchant 102 to select or input a personal identification number (PIN").
The Ul 706 can send the PIN to the
activation module 702, which can associate the PIN with the payment instrument
126 and/or a merchant profile
corresponding to the merchant 102. In at least one example, the merchant 102
can set a PIN at a later time, after
activation of the payment instrument 126.
[0103] In view of the foregoing, examples described herein provide
specific technical improvements over
.. conventional methods with streamlined automation and enhanced security
functionality in activating a payment
instrument.
[0104] FIG. 9 illustrates an example process 900 for activating a payment
instrument.
[0105] Block 902 illustrates determining a request to activate a payment
instrument associated with a stored
balance of a merchant that is maintained by a payment processing service. In
at least one example, the merchant
102 can interact with a Ul 706 for activating the payment instrument 126. In
at least one example, the Ul 706 can be
presented via a web browser, or the like. In other examples, the Ul 706 can be
presented via an application, such as
a mobile application or desktop application, which is provided by the payment
processing service, or which can be an
otherwise dedicated application. For instance, the Ul 706 can be presented via
the POS application 106 or an applet
(e.g., a balance applet, described below) associated with the POS application
106.
[0106] In some examples, the merchant 102 can log in to their payment
processing service account (e.g., which
corresponds to a merchant profile) via the POS application 106 to access the
Ul 706. In at least one example, the Ul
706 can include a selectable control that when selected initiates an
activation process. In some examples, the
selectable control can be made available via a status check of an ordered
payment instrument. That is, the merchant
17
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
102 can interact with the Ul 706 to check the status of their ordered payment
instrument 126 and, when the payment
instrument 126 is ready for activation, the merchant 102 the selectable
control can be availed to the merchant 102.
The merchant 102 can indicate a desire to activate the payment instrument 126,
for instance via selection of the
selectable control. In another example, the merchant 102 can provide a voice
input indicating that the merchant 102
desires to activate the payment instrument 126. In such examples, the POS
application 106 can determine a request
to active a payment instrument. In some examples, the POS application 106 can
send the request to the activation
module 702.
[0107] Block 904 illustrates prompting the merchant to cause an
interaction between the payment instrument and
the payment reader. In at least one example, the POS application 106 can
prompt (e.g., via the Ul 706) the merchant
102 to cause an interaction (e.g., a dip, tap, or swipe) between the payment
instrument 126 and the payment reader
704.
[0108] Block 906 illustrates receiving payment data associated with the
payment instrument from the payment
reader. The merchant 102 can cause the payment instrument 126 to interact with
the payment reader 704.
Responsive to such an interaction, the payment reader 704 can read payment
data 708 from the payment instrument
126. The payment data 708 can include, but is not limited to, a name of the
merchant 102, an address of the merchant
102, a type (e.g., credit, debit, etc.) of a payment instrument 126 from which
the payment data is accessed, a number
associated with the payment instrument 126, a verification value (e.g., PVKI,
PW, OW, CVC, etc.) associated with
the payment instrument 126, an expiration date associated with the payment
instrument 126, a PAN corresponding to
the merchant 102 (which can or may not match the number associated with the
payment instrument 126), restrictions
on what types of charges/debts can be made, etc. In some examples, the payment
data 708 can be encrypted. In
some examples, the POS application 106 can send the payment data 708 to the
activation module 702.
[0109] Block 908 illustrates determining whether the payment data
corresponds to known payment data
associated with the payment instrument. In at least one example, as
illustrated in FIG. 7, the activation module 702
can receive payment data 708 from the POS application 106 and can compare the
payment data 708 to known
payment data 710 associated with the payment instrument 126 provided to the
merchant 126. Known payment data
710 can include, but is not limited to, a name of the merchant 102, an address
of the merchant 102, a type (e.g., credit,
debit, etc.) of a payment instrument 126 from which the payment data is
accessed, a number associated with the
payment instrument 126, a verification value (e.g., PVKI, PW, OW, CVC, etc.)
associated with the payment
instrument 126, an expiration date associated with the payment instrument 126,
a PAN corresponding to the merchant
102 (which can or may not match the number associated with the payment
instrument 126), restrictions on what types
of charges/debts can be made, etc. In some examples, the known payment data
710 can be stored in the activation
module 702.
[0110] In an alternative example, as illustrated in FIG. 8, the
activation module 702 can provide the known payment
data 710 to the POS application 106 at some time prior to activation of the
payment instrument 126. In such an
example, the POS application 106 can temporarily store the known payment data
710. In such an example, the
payment reader 704 can read payment data 708 from the payment instrument 126.
The POS application 106 can
compare the payment data 708 to the known payment data 710.
18
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0111] Block 910 illustrates activating the payment instrument. In at
least one example, such as the example
described above with reference to FIG. 7, upon determining that the payment
data 708 matches, or otherwise
corresponds to, at least a portion of the known payment data 710, the
activation module 702 can send an activation
notification 712 to the POS application 106. The activation notification 712
can provide a notification to the merchant
.. 102 that the payment instrument 126 is activated. In at least one example,
the activation notification 712 can be
presented via the Ul 706.
[0112] In an alternate example, such as the example described above with
reference to FIG. 8, upon determining
that the payment data 708 matches, or otherwise corresponds to, at least a
portion of the known payment data 710,
the POS application 106 can send an activation notification 802 to the
activation module 702. The activation
notification 802 can provide a notification to the activation module 702 that
the payment instrument 126 is activated.
In some examples, responsive to receiving the activation notification 802, the
activation module 702 can indicate such
and can modify the default withdrawal channel associated with the stored
balance 120. In at least one example, the
activation module 702 can send a notification to the POS application 106 to
notify the merchant 102 of this modification.
Such a notification can be presented via the Ul 706.
[0113] Block 912 illustrates modifying a default withdrawal channel
associated with the stored balance.
Responsive to activating the payment instrument 126, the activation module 702
can modify the default withdrawal
channel associated with the stored balance 120. For example, in some
instances, until a payment instrument is linked
to a stored balance, scheduled deposits can be the default withdrawal channel.
However, upon activation of a payment
instrument, the activation module 702 can change the default withdrawal
channel to the payment instrument, thereby
.. allowing the stored balance 120 to increase. In such an example, the
activation module 702 can send an indication
to the merchant module 114 and/or the balance management module 118 to
temporarily freeze or deactivate
scheduled or instant deposits. Accordingly, funds from POS transactions can be
stored in the stored balance 120
instead of being deposited into a linked bank account of the merchant 102 per
a predetermined schedule (e.g., so the
stored balance 120 has funds to be spent via use of the payment instrument
126). In at least one example, the
.. activation module 702 can send a notification to the POS application 106 to
notify the merchant 102 of this modification.
Such a notification can be presented via the Ul 706.
[0114] It should be understood that upon a cancellation or deactivation
of the payment instrument 126, the
activation module 702 can terminate the association between the stored balance
120 and the payment instrument 126
and the activation module 702 can modify the default withdrawal channel to
scheduled deposits. Similarly, upon a
temporary freeze of the payment instrument 126, the activation module 702 can
update a merchant profile of the
merchant 102 to indicate that the payment instrument 126 is temporarily frozen
(e.g., unavailable) and can modify the
default withdrawal channel to scheduled deposits. Further, the merchant 102
can toggle between default withdrawal
channels at any time after activation.
[0115] In some examples, a merchant can deactivate, freeze, and/or cancel
a payment instrument by an
.. interaction as described above. That is, in at least one example, a
merchant can interact with a Ul to indicate a desire
to deactivate, freeze, or cancel a payment instrument and can cause a dip,
tap, or swipe between the payment
instrument and the payment reader 704. In response, the activation module 702
can deactivate, freeze, or cancel the
payment instrument, thereby "un-linking" the payment instrument from its
associated stored balance.
19
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0116] Block 914 illustrates refraining from activating the payment
instrument. If the payment data 708 and the
known payment data 710 do not match or otherwise correspond, the activation
module 702 or the POS application
106 can refrain from activating the payment instrument 126 and can present an
indication via the Ul 706 that the
activation failed.
[0117] FIG. 10 illustrates an example environment 1000 for tracking the
movement of funds in and out of a stored
balance and enabling a merchant associated with the stored balance to manage
their stored balance. FIG. 10 depicts
various components of FIG. 1. Additionally, FIG. 10 includes other merchant
device(s) 1002 and computing device(s)
of acquirer(s), card payment network(s), and/or issuer(s) 1004. As described
above, the merchant 102 can use the
payment instrument 126 (once activated) for making various purchases. In some
examples, such purchases can be
from another merchant that also subscribes to services of the payment
processing service. That is, another merchant
device 1002 can process a transaction between the other merchant and the
merchant 102 via an instance of the POS
application 106 on the other merchant device 1002. In other examples, the
merchant 102 can use the payment
instrument 126 (once activated) for making a purchase from a merchant that
does not subscribe to services of the
payment processing service.
[0118] In at least one example, payment instruments, such as the payment
instrument 126, can be associated
with one or more rewards or incentives to drive use by merchants. For
instance, in an example, to encourage the
merchant 102 to transact with other merchants that also subscribe to services
of the payment processing service, the
merchant 102 can receive a percentage of their transactions with other
merchants that subscribe to services of the
payment processing service back into their stored balance 120. That is, when
the merchant 102 uses the payment
instrument 126 to purchase an item from another merchant that subscribes to
services of the payment processing
service, the merchant module 114 can determine a predetermined amount (e.g., a
percentage, fixed amount, etc.) of
the cost of the item that is to be deposited into the stored balance 120. In
such an example, the other merchant
device(s) 1002 (e.g., the POS application 106) can send transaction data
associated with the transaction between the
merchant 102 and the other merchant to the merchant module 114. The merchant
module 114 can determine that the
payment data associated with the transaction is associated with the payment
instrument 126, which is linked to the
stored balance 120. The merchant module 114 can thus send an instruction to
the balance management module 118
to credit the stored balance 120 by a predetermined amount of the purchase
price, for example. As a result, the
balance management module 118 can credit the stored balance 120 in the
predetermined amount. In at least one
example, the predetermined amount can correspond to an amount of a payment
processing fee. In such an example,
the other merchant can still pay a payment processing fee, but the payment
processing service can transfer the amount
of the fee (or a portion thereof) to the stored balance 120 (to reward the
merchant 102 for shopping at another merchant
that subscribes to the payment processing service).
[0119] Similarly, merchants can be rewarded or otherwise receive a
discount for selling to, or otherwise transacting
with, other merchants that subscribe to services of the payment processing
service. For instance, in at least one
example, when the merchant 102 uses the payment instrument 126 to purchase an
item from another merchant that
subscribes to services of the payment processing service, the merchant module
114 can waive the payment
processing fee for the other merchant. In such an example, the other merchant
device(s) 1002 (e.g., the POS
application 106) can send transaction data associated with the transaction
between the merchant 102 and the other
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
merchant to the merchant module 114. The merchant module 114 can determine
that the payment data associated
with the transaction is associated with the payment instrument 126, which is
linked to the stored balance 120. The
merchant module 114 can thus send an instruction to the balance management
module 118 to credit the stored
balance of the other merchant by an amount of the purchase price without
reducing the amount of the purchase price
.. by the payment processing fee. As a result, the balance management module
118 can credit the stored balance of
the other merchant in the amount of the purchase price (or an amount based on
the purchase price).
[0120]
The server(s) 112 can be configured to communicate with computing device(s)
of acquirer(s), card payment
network(s), and/or issuer(s) 1004 to conduct financial transactions
electronically. For the sake of completeness, a
buyer can use a payment instrument at a POS device of a seller. In some
examples, the "buyer" can be a "merchant"
as used herein. The computing device at the POS can send a fund transfer
request for an amount of a transaction to
a computing device of an acquiring bank ("acquirer"). In an example, an
acquirer is a bank or financial institution that
processes payments (e.g., credit or debit card payments) and can assume risk
on behalf of sellers(s). An acquirer
can be a registered member of a card association (e.g., Visa , MasterCard ),
and can be part of a card payment
network. The acquirer (e.g., the associated computing device(s)) can send the
fund transfer request to a computing
device of a card payment network (e.g., Visa, MasterCard, Discover or American
Express) to determine whether the
transaction is authorized or deficient. In at least one example, the payment
processing service can serve as an
acquirer and connect directly with the card payment network.
[0121]
The card payment network (e.g., the associated computing device(s)) can
forward the fund transfer request
to the computing device of an issuing bank (e.g., "issuer"). The issuer is a
bank or financial institution that offers a
financial account (e.g., credit or debit card account) to the customer. An
issuer can issue payment cards to users and
can pay acquirers for purchases made by cardholders to which the issuing bank
has issued a payment card. The
issuer (e.g., the associated computing device(s)) can make a determination as
to whether the buyer has the capacity
to absorb the relevant charge associated with the payment transaction.
In at least one example, the payment
processing service can serve as an issuer and/or can partner with an issuer.
The transaction is either approved or
rejected by the issuer and/or the card payment network (e.g., the associated
computing device(s)), and a payment
authorization message is communicated from the issuer to the POS device via a
path opposite of that described above.
[0122]
Environment 1000 also includes a balance applet 1006. After the payment
instrument 126 is activated, the
merchant 102 can use the payment instrument 126 for making purchases from
other merchants (e.g., B2B, etc.). In
at least one example, the payment processing service¨via the balance
management module 118¨can track the
movement of funds in and out of the stored balance 120 (e.g., via the payment
instrument 126 or otherwise) and can
enable the merchant 102 to manage their stored balance 120 via an applet, such
as the balance applet 1006. In at
least one example, the balance applet 1006 can be available via a web browser,
or the like. In other examples, the
balance applet 1006 can be available via an application, such as a mobile
application or desktop application, which is
provided by the payment processing service, or which can be an otherwise
dedicated application. In at least one
example, the balance applet 1006 can be available via the POS application 106
on the merchant device 104, as
illustrated in FIG. 10.
[0123]
In conventional technologies, merchants are required to access various
reports to view recent deposits,
various withdrawals, etc. Often, the time of day can impact which report a
merchant needs to access to view such
21
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
information. This can be confusing for merchants and causes a poor user
experience. Further, multiple reports cause
various inefficiencies. The balance applet 1006 can integrate multiple reports
and functions into a single access point,
thereby improving user interaction with the POS application 106 and/or
merchant device 104. That is, the balance
applet 1006 can offer a cohesive means of accessing various reports and
functionalities. As non-limiting examples,
the balance applet 1006 can enable the merchant 102 to check how much money
they are earning (e.g., via
presentation of available earned balance), understand where their money is
going (e.g., via deposit reports (which can
include a breakdown of fees), spend reports, etc.), access/use earned money
(e.g., via scheduled deposit, instant
deposit, linked payment instrument, etc.), feel in control of their money
(e.g., via management of deposit schedule,
deposit speed, linked instruments, etc.), etc. Furthermore, the balance applet
1006 can enable merchants to visualize
their cash flow to track their financial health, set aside money for upcoming
obligations (e.g., savings), organize money
around goals, etc.
[0124] In at least one example, the balance management module 118 can
track the movement of funds in and out
of the stored balance 120. The balance management module 118 can manage
accounting of the stored balance 120.
That is, the balance management module 118 can maintain a summary of all
amounts debited or credited from the
stored balance 120. In at least one example, the balance management module 118
can maintain the summary via a
ledger, which can be a journal or other record-keeping mechanism that includes
individual indications corresponding
to each transaction. Each individual indication of a transaction in the ledger
can be associated with transaction data
and, in at least one example, the individual indications of the transactions
can be arranged by date. In at least one
example, an individual indication can be associated with an electronic record
of the transaction (e.g., a receipt).
[0125] In at least one example, the balance management module 118 can
credit the stored balance 120 based
on funds received from POS transactions. For instance, the merchant module 114
can send an instruction to the
balance management module 118 to add an amount to the stored balance 120. The
amount can correspond to a cost
of a transaction, or a portion thereof. In another example, the amount can
correspond to costs of multiple transactions
(or portions thereof). Additionally, the balance management module 118 can
credit the stored balance 120 based on
.. funds received from the linked bank account 122 of the merchant 102. That
is, in some examples, the merchant 102
can request funds to be deposited into the stored balance 120 from its linked
bank account 122.
[0126] Funds can be credited to the stored balance 120 via additional
means that are within the scope of this
disclosure. For instance, the balance management module 118 can credit the
stored balance 120 based on a capital
loan issued to the merchant 102. A capital loan is a loan, for instance from
the payment processing service to a
borrower, that is to be used for, in some instances, financing the borrower's
short-term operational needs. For
instance, a potential borrower that is a merchant can obtain a capital loan
via a capital loan product in order to finance
various operational costs (e.g., rent, payroll, inventory, etc.). In an
example, the merchant 102 can obtain a capital
loan from the payment processing service. In such an example, the balance
management module 118 can credit the
stored balance 120 in an amount of the capital loan. Furthermore, in some
examples, the merchant 102 can receive
a refund, the amount of which can be deposited into the stored balance 120 of
the merchant 102. In such an example,
the balance management module 118 can credit the stored balance 120 in an
amount of the refund. Moreover, in at
least one example, the merchant 102 can receive a reward, the amount of which
can be deposited into the stored
22
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
balance 120 of the merchant 102. In such an example, the balance management
module 118 can credit the stored
balance 120 in an amount of the reward.
[0127] In some examples, the merchant 102 can indicate that the merchant
102 desires to withhold at least some
funds for another purpose, such as savings (e.g., for taxes, for a large
purchase, for reserve funds, etc.). In such
examples, the balance management module 118 can credit a portion of a POS
transaction, for instance, to the stored
balance 120, and can withhold a portion of the POS transaction from the stored
balance 120. The portion of the POS
transaction withheld from the stored balance 120 can be credited to a savings
account linked to the stored balance
120, a sub-account within the stored balance 120, etc.
[0128] In at least one example, the balance management module 118 can
debit the stored balance 120 based on
scheduled deposits, instant deposits, and transactions using the payment
instrument 126, as described above. In
some examples, a scheduled deposit and/or an instant deposit can cause all of
the funds in the stored balance 120 to
be deposited into the linked bank account 122. In other examples, a portion of
funds can remain in the stored balance
120 and a portion of funds can be deposited into the linked bank account 120.
In any case, the balance management
module 118 can debit the stored balance 120 in an amount corresponding to the
amount of funds transferred to the
linked bank account 122. The balance management module 118 can additionally or
alternatively debit the stored
balance 120 based on transactions between the merchant 102 and other
merchants. That is, for a transaction
completed using the payment instrument 126, the balance management module 118
can debit an amount of the
transaction from the stored balance 120. In some examples, the merchant 102
can use the payment instrument 126
to withdraw cash from an ATM. In such examples, the balance management module
118 can debit an amount of the
withdrawal from the stored balance 120.
[0129] In some examples, the merchant 120 can use the stored balance 120
for paying bills. In at least one
example, the merchant 120 can set up an automatic bill pay using the stored
balance 120. In other examples, the
merchant 120 can use the stored balance 120 for one-time bill pay. In either
case, the balance management module
118 can debit an amount of the bill(s) from the stored balance 120.
Furthermore, the merchant 120 can use the stored
balance 120 to repay a capital loan, as described above. In such an example,
the balance management module 118
can debit the stored balance 120 in an amount equal to repayment of a capital
loan.
[0130] Other debits are within the scope of this disclosure. For
instance, in at least one example, the merchant
102 can make payroll payments via the stored balance 120. In such an example,
the merchant 102 can request to
transfer funds from the stored balance 120 to bank accounts of employees of
the merchant 102. The balance
management module 118 can debit an amount corresponding to a payroll payment
from the stored balance 120.
Similarly, the merchant 102 can order inventory via the payment processing
service. In such examples, the payment
processing service can facilitate a transfer of funds from the stored balance
120 of the merchant 102 to a stored
balance of another merchant. The balance management module 118 can debit an
amount corresponding to such a
purchase from the stored balance 120.
[0131] Furthermore, the balance management module 118 can track fees (e.g.,
payment processing fees, capital
loan repayment fees, interest, etc.) and debit such fees from the stored
balance 120. Furthermore, in some examples,
the merchant 102 can be penalized with a chargeback (e.g., a demand by a
computing device(s) of acquirer(s), card
payment network(s), and/or issuer(s) 1004 for the merchant 102 to make good on
the loss on a fraudulent or disputed
23
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
transaction), the amount of which can be withdrawn from the stored balance 120
of the merchant 102. In such an
example, the balance management module 118 can debit the stored balance 120 in
an amount of the chargeback.
[0132] In some examples, if the stored balance 120 is insufficient to
cover a debit (e.g., a bill, payroll payment,
chargeback, etc.), the balance management module 118 can send a request for
funds from the linked bank account
122. If a bank account is not linked to the merchant profile of a merchant,
the merchant can be required to provide
bank account data for linking a bank account to the merchant profile. In other
examples, the payment processing
service can send an offer for a capital loan to cover the deficiency.
Additionally or alternatively, the payment processing
service can float the deficiency and collect the deficiency from POS
transaction funds received in the future.
[0133] Furthermore, in at least one example, the balance management
module 118 can analyze the individual
transactions to determine whether such transactions are business transactions
or personal transactions (e.g., classify
the transactions). In such an example, the balance management module 118 can
utilize a machine-trained model to
output an indication of whether an individual transaction is a business
transaction or a personal transaction. The
balance management module 118 can add an indicator of such to the indication
of the transaction in the ledger. As
described below, the merchant 102 can interact with a Ul to modify the
classification.
[0134] In at least one example, the machine-trained model can be trained
via a machine learning mechanism. In
such an example, the model can be trained using supervised learning algorithms
(e.g., artificial neural networks,
Bayesian statistics, support vector machines, decision trees, classifiers, k-
nearest neighbor, etc.), unsupervised
learning algorithms (e.g., artificial neural networks, association rule
learning, hierarchical clustering, cluster analysis,
etc.), semi-supervised learning algorithms, deep learning algorithms, etc. In
at least one example, the model can be
trained on training data associated with a plurality of merchants. The
training data can include a plurality of
transactions and associated transaction data, and merchant data associated
with merchants participating in the
plurality of transactions. As a result, the machine-trained model can output a
prediction that a particular transaction is
associated with a business transaction of the merchant or a personal
transaction. As a non-limiting example, the
machine-trained model can classify a purchase of shampoo as a business
transaction for a merchant that provides
salon services but can classify a purchase of shampoo as a personal
transaction for a merchant that provides
restaurant services.
[0135] The balance applet 1006 can enable the merchant 102 to access and
view a Ul representative of the ledger
(or a portion thereof) corresponding to its stored balance 120. In at least
one example, the balance applet 1006 can
present a Ul that presents the current value of the stored balance 120 and
includes indications of credits, debits, etc.
In some examples, a portion of the ledger representing the most recent
transactions can be presented, while the entire
ledger can be accessible via an interaction with the Ul. In at least one
example, the credits, debits, etc. can be
itemized. In other examples, the credits, debits, etc. can be aggregated, for
instance by date, creditor/debtor, type of
credit/debit, etc. In some examples, the Ul can indicate an estimated date of
an expected credit or debit, if applicable.
[0136] The balance applet 1006 can also enable the merchant 102 to manage
its stored balance 120. That is, the
Ul can enable the merchant 102 to schedule (or modify an existing schedule
for) a scheduled deposit, request an
instant deposit, order a payment instrument, etc. In at least one example, the
balance applet 1006 can enable the
merchant 102 to check the status of an ordered payment instrument, cancel
and/or deactivate a payment instrument
(e.g., if the payment instrument 126 is lost or stolen), reorder a new payment
instrument, temporarily freeze a payment
24
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
instrument, etc. Furthermore, the balance applet 1006 can enable the merchant
102 to access their pending deposit
balance, deposit reports, deposit schedules, spend reports, linked accounts
and/or payment instruments, etc. In some
examples, the balance applet 1006 can enable the merchant 102 to access sales
reports. The balance applet 1006
can additionally enable the merchant 102 to change their deposit speeds,
update their close of day, link new bank
accounts, modify default withdrawal channels (e.g., from scheduled deposit to
maintaining funds in the stored balance
120, from maintaining funds in the stored balance 120 to scheduled deposits,
etc.), etc. Further, in some examples,
the balance applet 1006 can surface information about unusual activity,
suspicious activity, etc.
[0137] In at least one example, the merchant 102 can access the balance
applet 1006 by causing the payment
instrument 126 to interact (e.g., via a swipe, dip, or tap) with a payment
reader (e.g., the payment reader 704). For
example, the merchant 102 can swipe the payment instrument 126 via the payment
reader 704. The payment reader
704 can read the payment data off the payment instrument 126 and transmit the
payment data to the POS application
106. The POS application 106 can determine that the payment data corresponds
to the payment instrument 126 and
can open the balance applet 1006. That is, responsive to receiving the payment
data associated with the payment
instrument 126, the POS application 106 can cause the Ul of the balance applet
1006 to be presented via the merchant
device 104. In at least one example, the payment data can be received at a
time independent of a transaction. That
is, in such an example, the POS application 106 can receive the payment data
at a time independent of a transaction
and determine that the payment data corresponds to the payment instrument 126.
Responsive to the payment data
being received at a time separate from a transaction, the POS application 106
can open the balance applet 1006.
[0138] In at least one example, access to the balance applet 1006 can be
limited by one or more permissions.
.. For instance, the balance applet 1006 can be accessible to an owner and/or
administrator of the merchant 102, but
not to an employee of the merchant 102. Or, individual functions of the
balance applet 1006 can be accessible to an
employee and other individual functions can be limited. In at least one
example, an employee of the merchant 102
can attempt to access the balance applet 1006. The employee can be logged into
the POS application 106 via a
unique identifier. The POS application 106 can compare the unique identifier
to one or more unique identifiers that
.. have permission to access the balance applet 1006 and, if the unique
identifier is not one of the one or more unique
identifiers, the POS application 106 can deny the employee access to the
balance applet 1006. In another example,
some aspects of the balance applet 1006 can be available to the employee but
other aspects may not. In yet another
example, upon receiving a request to access the balance applet 1006, the POS
application 106 can request a
permission code to be entered. If the permission code is provided, the POS
application 106 can enable access to the
balance applet 1006. If the permission code is not provided, the POS
application 106 can deny access to the balance
applet 1006. In another example, some aspects of the balance applet 1006 can
be available but other aspects may
not. That is, failure to provide the correct permission code can cause at
least some functionality of the balance applet
1006 to be inaccessible.
[0139] FIG. 11 illustrates an example process 1100 for presenting a Ul
representative of the ledger (or a portion
thereof) corresponding to its stored balance.
[0140] Block 1102 illustrates receiving, from a merchant device of a
merchant, a request to access information
associated with a stored balance of the merchant. In at least one example, the
merchant 102 can interact with a Ul
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
presented in association with the POS application 106 to request access to
their stored balance 120. In at least one
example, responsive to receiving such a request, the POS application 106 can
open the balance applet 1006.
[0141] Block 1104 illustrates accessing a ledger associated with the
stored balance. In at least one example, the
balance applet 1006 can send a request to access the ledger associated with
the stored balance 120. The balance
management module 118 can receive the request and can access the ledger.
[0142] Block 1106 illustrates sending instructions for presenting a user
interface associated with the ledger via a
display of the merchant device. The balance management module 118 can generate
and send instructions to the
balance applet 1006 to enable the balance applet 1006 to present a graphical
representation of the ledger, or a portion
thereof.
[0143] Block 1108 illustrates causing the user interface to be presented
via a display of the merchant device. As
described above, the balance applet 1006 can present a Ul that presents the
current value of the stored balance 120
(e.g., 1202) and includes indications 1204 of credits, debits, etc. In some
examples, a portion of the ledger
representing the most recent transactions can be presented, while the entire
ledger can be accessible via an
interaction with the Ul. In at least one example, the credits, debits, etc.
can be itemized. In other examples, the
credits, debits, etc. can be aggregated, for instance by date,
creditor/debtor, type of credit/debit, etc. In some
examples, the Ul can indicate an estimated date of an expected credit or
debit, if applicable.
[0144] FIG. 12 illustrates an example Ul 1200 for presenting at least a
portion of a ledger of a stored balance of a
merchant.
[0145] As described above, the balance applet 1006 can enable the
merchant 102 to access and view a Ul
representative of the ledger (or a portion thereof) corresponding to its
stored balance 120. In at least one example,
the balance applet 1006 can present a Ul that presents the current value of
the stored balance 120 (e.g., 1202) and
includes indications 1204 of credits, debits, etc. In some examples, a portion
of the ledger representing the most
recent transactions can be presented, while the entire ledger can be
accessible via an interaction with the Ul. In at
least one example, the credits, debits, etc. (e.g., 1204) can be itemized. In
other examples, the credits, debits, etc.
can be aggregated, for instance by date, creditor/debtor, type of
credit/debit, etc. In some examples, the Ul can
indicate an estimated date of an expected credit or debit, if applicable.
[0146] The balance applet 1006 can also enable the merchant 102 to manage
its stored balance 120. That is, the
Ul can enable the merchant 102 to schedule (or modify an existing schedule
for) a scheduled deposit, request an
instant deposit, order a payment instrument, etc. As an example, Ul 1200
includes a selectable control 1206 that
enables the merchant 102 to transfer at least a portion of the funds in the
stored balance 120 to their bank account
122 "now" (e.g., via an instant deposit). As another example, Ul 1200 includes
a selectable control 1208 that enables
the merchant 102 to transfer at least a portion of the funds in the stored
balance 120 to their bank account 122 "later
(e.g., via a scheduled deposit).
[0147] Furthermore, the balance applet 1006 can enable the merchant 102
to access their pending deposit
balance, deposit reports, deposit schedules, spend reports, linked accounts
and/or payment instruments, etc. In at
least one example, the Ul 1200 can include selectable controls 1210, that when
selected, cause corresponding reports
to be presented to the merchant 102. In some examples, such reports can open
in the same Ul 1200. In other
examples, such reports can open in a new window, which may or may not overlay
the Ul 1200.
26
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0148] In at least one example, the balance applet 1006 can enable the
merchant 102 to manage their linked
payment instrument, for instance by enabling the merchant 102 to check the
status of an order payment instrument,
cancel and/or deactivate a payment instrument (e.g., if the payment instrument
126 is lost or stolen), reorder a new
payment instrument, temporarily freeze a payment instrument, etc., such as via
interaction with a selectable control
1212 that causes one or more payment instrument management Uls to be
presented. In some examples, such Ul(s)
can open in the same Ul 1200. In other examples, such Ul(s) can open in a new
window, which may or may not
overlay the Ul 1200.
[0149] Ul 1200 is but one example of a Ul that can present at least a
portion of the ledger associated with the
stored balance 120 and other functionalities availed via the balance applet
1006 and other configurations and designs
are capable of presenting the same information and/or enabling access to the
same functionalities.
[0150] As described above, in at least one example, the merchant 102 can
access the balance applet 1006 by
causing the payment instrument 126 to interact (e.g., via a swipe, dip, or
tap) with a payment reader (e.g., the payment
reader 704). FIG. 13 illustrates an example process 1300 for opening a balance
applet responsive to an interaction
between a payment instrument interacting with a payment reader.
[0151] Block 1302 illustrates receiving, via a POS application on a
merchant device of a merchant, payment data
independent of a POS transaction. In at least one example, the merchant 102
can cause an interaction (e.g., a dip, a
tap, or a swipe) between the payment instrument 126 and the payment reader
704. The payment reader 704 can read
the payment data off the payment instrument 126 and can transmit the payment
data to the POS application 106. The
POS application 106 can receive the payment data. The POS application 106, as
described above, can be used for
processing transactions at the POS. Accordingly, the POS application 106 can
know whether the payment data is
received in association with a POS transaction. In at least one example, when
the merchant 102 desires to access
the balance applet 1006, the payment data can be received independent of a POS
transaction.
[0152] Block 1304 illustrates determining whether the payment data
corresponds to known payment data of a
payment instrument linked to a stored balance of a merchant. In at least one
example, the POS application 106 can
determine whether the payment data corresponds to known payment data
associated with a payment instrument. In
some examples, the POS application 106 can store the known payment data of the
payment instrument 126 such that
the POS application 106 can determine that the payment data corresponds to the
known payment data. Responsive
to receiving the payment data associated with the payment instrument 126, the
POS application 106 can cause the Ul
of the balance applet 1006 to be presented via the merchant device 104, as
illustrated in block 1306. If the payment
data does not correspond to the known payment data, the POS application 106
can cause an error message to be
presented via the merchant device 104.
[0153] As described above, the balance management module 118 can analyze
the individual transactions to
determine whether such transactions are business transactions or personal
transactions (e.g., classify the
transactions). The balance management module 118 can add an indicator of such
to the indication of the transaction
in the ledger, which can be surfaced via the Ul presented via the balance
applet 1006.
[0154] FIG. 14 illustrates an example process 1400 for classifying
transactions.
[0155] Block 1402 illustrates receiving transaction data associated with
transaction(s) between a merchant and
other merchants. In at least one example, the balance management module 118
can receive transaction data. In
27
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
some examples, the transaction data can be received from the merchant module
114, for instance when the other
merchants subscribe to services of the payment processing service. In other
examples, the transaction data can be
received from computing device(s) of acquirer(s), card payment network(s),
and/or issuer(s) 1004. The transaction
data can include payment data, user authentication data, purchase amount
information, point-of-purchase information
(e.g., item(s) purchased, date of purchase, time of purchase, etc.), etc.
[0156] Block 1404 illustrates adding an indication of each transaction to
a ledger maintained by a payment
processing service. As described above, the balance management module 118 can
manage accounting of the stored
balance 120. That is, the balance management module 118 can maintain a summary
of all amounts debited or credited
from the stored balance 120. In at least one example, the balance management
module 118 can maintain the
summary via a ledger, which can be a journal or other record-keeping mechanism
that includes individual indications
corresponding to each transaction. Each individual indication of a transaction
in the ledger can be associated with
transaction data and, in at least one example, the individual indications of
the transactions can be arranged by date.
[0157] Block 1406 illustrates determining whether a transaction is a
business expense or a personal expense. As
described above, in at least one example, the balance management module 118
can analyze the individual
transactions to determine whether such transactions are business transactions
or personal transactions (e.g., classify
the transactions). In such an example, the balance management module 118 can
utilize a machine-trained model to
output an indication of whether an individual transaction is a business
transaction or a personal transaction. The
balance management module 118 can add an indicator of such to the indication
of the transaction in the ledger. For
instance, responsive to determining that the transaction is associated with a
business expense, the balance
management module 118 can associate a first indication with the indication of
the transaction in the ledger, as
illustrated in block 1408. And, responsive to determining that the transaction
is associated with a personal expense,
the balance management module 118 can associate a second indicator with the
indication of the transaction in the
ledger, as illustrated in block 1410. The first indicator and the second
indicator can enable the merchant 102 to visually
distinguish between business transactions and personal transactions. As
described below, the merchant 102 can
interact with a Ul to modify the classification.
[0158] FIG. 15 is an example Ul 1500 for presenting at least a portion of
a ledger of a stored balance of a merchant,
wherein individual transactions are associated with an indicator as to whether
the transaction is a business expense
or a personal expense. As described above, the balance applet 1006 can enable
the merchant 102 to access and
view a Ul representative of the ledger (or a portion thereof) corresponding to
its stored balance 120. Details associated
with such a Ul are described above with reference to FIG. 12.
[0159] In at least one example, as described above with reference to FIG.
14, the balance management module
118 can classify transactions (e.g., as business or personal expenses) and can
add indicators to corresponding
indications in the ledger. FIG. 15 illustrates graphical representations 1502
of such indicators. The graphical
representations 1502 are provided for illustrative purposes and any design or
configuration can be used to denote that
a transaction is a business expense or a personal expense. In at least one
example, the merchant 102 can interact
with the Ul 1500 to classify or modify the classification of a transaction.
For instance, one of the indicators 1504 is
enlarged so that details can be observed. As illustrated, the indicator 1504
is a toggle, which allows the merchant 102
to indicate whether the corresponding transaction is a business expense or a
personal expense. In at least one
28
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
example, the Ul can present the indicators 1502 based on classifications by
the balance management module 118 or
previous classifications (or corrections) by the merchant 102.
[0160] Ul 1500 is but one example of a Ul that can present at least a
portion of the ledger associated with the
stored balance 120 and other functionalities availed via the balance applet
1006 and other configurations and designs
are capable of presenting the same information and/or enabling access to the
same functionalities.
[0161] FIG. 16 illustrates an example process 1600 for associating
electronic records with indications of
transactions in a ledger.
[0162] Block 1602 illustrates receiving transaction data associated with
transaction(s) between a merchant and
other merchants. In at least one example, the balance management module 118
can receive transaction data. In
some examples, the transaction data can be received from the merchant module
114, for instance when the other
merchants subscribe to services of the payment processing service. In other
examples, the transaction data can be
received from computing device(s) of acquirer(s), card payment network(s),
and/or issuer(s) 1004. The transaction
data can include payment data, user authentication data, purchase amount
information, point-of-purchase information
(e.g., item(s) purchased, date of purchase, time of purchase, etc.), etc.
[0163] Block 1604 illustrates adding an indication of each transaction to a
ledger maintained by a payment
processing service. As described above, the balance management module 118 can
manage accounting of the stored
balance 120. That is, the balance management module 118 can maintain a summary
of all amounts debited or credited
from the stored balance 120. In at least one example, the balance management
module 118 can maintain the
summary via a ledger, which can be a journal or other record-keeping mechanism
that includes individual indications
corresponding to each transaction. Each individual indication of a transaction
in the ledger can be associated with
transaction data and, in at least one example, the individual indications of
the transactions can be arranged by date.
[0164] Block 1606 illustrates associating an electronic record of a
transaction with a corresponding indication of
the transaction in the ledger. In at least one example, an individual
indication can be associated with an electronic
record of the transaction (e.g., a receipt). That is, in some examples, the
transaction data can include an electronic
record of the transaction. The balance management module 118 can associate the
electronic record with the indication
of the transaction. In at least one example, the electronic record can be
presented to the merchant 102, responsive
to the merchant 102 interacting with a Ul presenting at least a portion of the
ledger.
[0165] FIG. 17 is an example Ul 1700 for presenting at least a portion of
a ledger of a stored balance of a merchant,
wherein individual transactions are associated with electronic records of the
individual transactions. As described
above, the balance applet 1006 can enable the merchant 102 to access and view
a Ul representative of the ledger (or
a portion thereof) corresponding to its stored balance 120. Details associated
with such a Ul are described above with
reference to FIG. 12.
[0166] In at least one example, individual indications of transactions in
the ledger can be associated with
selectable controls that enable the merchant 102 to view corresponding
electronic records. For instance, when the
merchant 102 actuates a selectable control corresponding to a transaction, the
balance applet 1006 can cause an
electronic record 1702 corresponding to that transaction to be presented via
the Ul 1700. In some examples, the
electronic record 1702 can be presented as an overlay, as illustrated in FIG.
17. However, in other examples, the
electronic record 1702 can be presented within the Ul or via another Ul.
29
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0167] Ul 1700 is but one example of a Ul that can present at least a
portion of the ledger associated with the
stored balance 120 and other functionalities availed via the balance applet
1006 and other configurations and designs
are capable of presenting the same information and/or enabling access to the
same functionalities.
[0168] FIG. 18 illustrates an example process 1800 for intelligently
managing authorization requests. As
described above, in an example, when a payment processing service controls a
payment instrument, such as they
payment instrument 126 that is linked to the stored balance 120, and receives
an authorization request in association
with a transaction, instead of automatically declining (if account balance is
below the amount of the authorization
request), the payment processing service can approve the authorization request
(and thus, temporarily cover the cost
of the transaction) if the payment processing service believes that the
ultimately charged amount will be less than or
equal to the account balance.
[0169] Conventional techniques immediately decline a transaction if the
available balance of a payment instrument
is insufficient to satisfy a predicted cost of a transaction, or permit the
transaction, but penalize the buyer with an
overdraft charge. Techniques described herein reduce the number of declines
experienced by payment instrument
users, thereby improving user experience and decreasing frustration caused by
conventional authorization request
management. Furthermore, the unconventional techniques described herein are
directed to decongesting networks
associated with payment processing and increasing bandwidth within the payment
processing network.
[0170] Block 1802 illustrates receiving an authorization request to
authorize a payment for a predicted cost of a
transaction. In at least one example, a buyer can use a payment instrument to
pay for a transaction with a seller. For
instance, the merchant 102 (e.g., the buyer) can use the payment instrument
126 linked to their stored balance 120 to
pay for a transaction with another merchant (e.g., the seller). In at least
one example, a POS device can send payment
data to a computing device of an acquirer. In some examples, the actual cost
of the transaction may not be known
and thus the POS device (or application running thereon) can predict a cost of
the transaction (e.g., "predicted cost").
A computing device of the acquirer can send a request for a transfer of funds
to a computing device of a card payment
network. The computing device of the card payment network can forward the
request to a computing device of an
issuer of the payment instrument. In some examples, the payment processing
service can be the acquirer, card
payment network, and/or the issuer (or a partner of the issuer).
[0171] Block 1804 illustrates determining whether the predicted cost is
greater than an available balance of the
payment instrument. In at least one example, the merchant module 114 can
determine an available balance
associated with the payment instrument. In some examples, the available
balance can correspond to a stored balance
(e.g., the stored balance 120) that is linked to the payment instrument (e.g.,
the payment instrument 126) and managed
via a ledger associated with the payment processing service. In other
examples, the available balance can be
associated with a gift card balance, credit card limit, etc. In at least one
example, the merchant module 114 can
communicate with the computing device(s) of acquirer(s), card payment
network(s), and/or issuer(s) 1004 and/or
access the stored balance 120 (if applicable) to ascertain the available
balance of the payment instrument. The
merchant module 114 can compare the predicted cost of the transaction to the
available balance of the payment
instrument. If the predicted cost of the transaction is less than or equal to
the available balance, the merchant module
114 can approve the transaction, as illustrated in block 1806. If the
predicted cost of the transaction is greater than
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
the available balance, the merchant module 114 can determine whether the
actual cost of the transaction is likely to
be greater than the available balance of the payment instrument.
[0172]
Block 1808 illustrates determining whether the actual cost is likely to be
greater than the available balance
of the payment instrument. In at least one example, the merchant module 114
can utilize a machine-trained model to
predict the actual cost of the transaction. In at least one example, the
machine-trained model can be trained via a
machine learning mechanism. In such an example, the model can be trained using
supervised learning algorithms
(e.g., artificial neural networks, Bayesian statistics, support vector
machines, decision trees, classifiers, k-nearest
neighbor, etc.), unsupervised learning algorithms (e.g., artificial neural
networks, association rule learning, hierarchical
clustering, cluster analysis, etc.), semi-supervised learning algorithms, deep
learning algorithms, etc. In at least one
example, the model can be trained on training data associated with a plurality
of merchants and POS transactions.
The training data can include a plurality of POS transactions and associated
transaction data, which can be itemized.
As a result, the machine-trained model can output a prediction of an actual
cost of an item and/or item(s) in a
transaction.
[0173]
In at least one example, the machine-trained model can output a prediction
of an actual cost of an item
and/or item(s) based on transaction data associated with other merchants that
are similar to a seller in a transaction.
For instance, the machine-trained model can output a prediction based on item
prices offered for sale by other
merchants in a same MCC, a same geolocation, a same price-point, etc. as the
seller in the transaction. In an
additional or alternative example, the machine-trained model can output a
prediction of an actual cost of an item and/or
item(s) based on transaction data associated with transactions that are
similar to the transaction. For instance, the
machine-trained model can output a prediction based on item prices of items in
transactions with one or more of the
same parties (e.g., buyer and/or seller), transactions in a same geolocation,
transactions at a same time, etc.
[0174]
Based at least in part on determining that the actual cost is not likely to
be greater than the available
balance of the payment instrument, the merchant module 114 can authorize the
transaction, as illustrated in block
1806. However, based at least in part on determining that the actual cost is
likely to be greater than the available
balance of the payment instrument, the merchant module 114 can, in one
example, present a capital offer to the buyer,
as illustrated in block 1810. In another example, the merchant module 114 can
deny the transaction (which is not
shown) or, the merchant module 114 can authorize the transaction, as
illustrated in block 1806, and can collect a
difference between the actual cost of the transaction and the available
balance via funds received by the buyer from
future POS transactions (e.g., when using the payment processing service for
processing POS transactions). In such
an example, the payment processing service can float the difference between
the actual cost of the transaction and
the available balance (thereby not declining the transaction) and can recover
the difference via withholding funds from
future POS transactions processed by the merchant module 114. In such an
example, the transaction is not treated
as an overdraft, and the buyer can proceed with the transaction.
[0175]
Block 1810 illustrates presenting a capital offer to the buyer. As
described above, a capital loan is a loan,
for instance from the payment processing service to a borrower, that is to be
used for, in some instances, financing
the borrower's short-term operational needs. For instance, a potential
borrower that is a merchant can obtain a
capital loan via a capital loan product in order to finance a difference
between the available balance of the payment
instrument and the actual cost of the transaction. In at least one example,
the merchant module 114 can determine a
31
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
difference between the available balance of the payment instrument and the
actual cost of the transaction (as predicted
per block 1808 above). The merchant module 114 can leverage one or more risk
analyses to determine whether the
buyer qualifies for a capital loan and an amount of a capital loan for which
they are qualified. If the buyer qualifies for
a capital loan, the merchant module 114 can send a capital loan offer to the
buyer (e.g., via a computing device
associated with the buyer) in an amount at least equal to the difference
between the available balance of the payment
instrument and the actual cost of the transaction.
[0176] Block 1812 illustrates determining whether the buyer accepts the
capital offer. Based at least in part on
the buyer accepting the capital offer, the merchant module 114 can authorize
the transaction, as illustrated in block
1806. In some examples, if the payment instrument is associated with a stored
balance maintained by the payment
processing service, the balance management module 118 can add the amount of
the capital loan to the stored balance
(e.g., as a credit).
[0177] In at least one example, the buyer may not accept the capital
offer. In such an example, the merchant
module 114 can deny the transaction (which is not shown) or, the merchant
module 114 can authorize the transaction,
as illustrated in block 1806, and can collect a difference between the actual
cost of the transaction and the available
balance via funds received by the buyer from future POS transactions. In such
an example, the payment processing
service can float the difference between the actual cost of the transaction
and the available balance (thereby not
declining the transaction) and can recover the difference via withholding
funds from future POS transactions processed
by the merchant module 114. In such an example, the transaction is not treated
as an overdraft, and the buyer can
proceed with the transaction.
[0178] While FIG. 18 makes reference to using the payment instrument 126,
which is linked to the stored balance
120, payment transactions using any payment instrument can be handled in a
same or similar way.
[0179] FIG. 19 depicts an illustrative block diagram illustrating a
system 1900 for performing techniques described
herein. The system 1900 includes a merchant device 104, that communicates with
server computing device(s) (e.g.,
server(s) 112) via network(s) 1902 (e.g., the Internet, cable network(s),
cellular network(s), wireless network(s) (e.g.,
.. Wi-Fi) and wired network(s), as well as close-range communications such as
Bluetooth , Bluetooth low energy, and
the like). While a single merchant device 104 is illustrated, in additional or
alternate examples, the system 1900 can
have multiple merchant devices. Similarly, while the aforementioned
description describes a single stored balance
and merchant, in additional or alternative examples, the system 1900 can have
multiple merchants and stored
balances.
[0180] In at least one example, the merchant device 104 can be any suitable
type of computing device, e.g.,
portable, semi-portable, semi-stationary, or stationary. Some examples of the
merchant device 104 can include tablet
computing devices; smart phones and mobile communication devices; laptops,
netbooks and other portable computers
or semi-portable computers; desktop computing devices, terminal computing
devices and other semi-stationary or
stationary computing devices; dedicated register devices; wearable computing
devices, or other body-mounted
computing devices; augmented reality devices; or other computing devices
capable of sending communications and
performing the functions according to the techniques described herein.
[0181] In the illustrated example, the merchant device 104 includes one
or more processors 1904, one or more
computer-readable media 1906, one or more communication interfaces 1908, and
one or more input/output (I/O)
32
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
devices 1910. Each processor 1904 can itself comprise one or more processors
or processing cores. For example,
the processor(s) 1904 can be implemented as one or more microprocessors,
microcomputers, microcontrollers, digital
signal processors, central processing units, state machines, logic
circuitries, and/or any devices that manipulate
signals based on operational instructions. In some examples, the processor(s)
1904 can be one or more hardware
processors and/or logic circuits of any suitable type specifically programmed
or configured to execute the algorithms
and processes described herein. The processor(s) 1904 can be configured to
fetch and execute computer-readable
processor-executable instructions stored in the computer-readable media 1906.
[0182] Depending on the configuration of the merchant device 104, the
computer-readable media 1906 can be an
example of tangible non-transitory computer storage media and can include
volatile and nonvolatile memory and/or
removable and non-removable media implemented in any type of technology for
storage of information such as
computer-readable processor-executable instructions, data structures, program
modules or other data. The computer-
readable media 1906 can include, but is not limited to, RAM, ROM, EEPROM,
flash memory, solid-state storage,
magnetic disk storage, optical storage, and/or other computer-readable media
technology. Further, in some examples,
the merchant device 104 can access external storage, such as RAID storage
systems, storage arrays, network
attached storage, storage area networks, cloud storage, or any other medium
that can be used to store information
and that can be accessed by the processor(s) 1904 directly or through another
computing device or network.
Accordingly, the computer-readable media 1906 can be computer storage media
able to store instructions, modules
or components that can be executed by the processor(s) 1904. Further, when
mentioned, non-transitory computer-
readable media exclude media such as energy, carrier signals, electromagnetic
waves, and signals per se.
[0183] The computer-readable media 1906 can be used to store and maintain
any number of functional
components that are executable by the processor(s) 1904. In some
implementations, these functional components
comprise instructions or programs that are executable by the processor(s) 1904
and that, when executed, implement
operational logic for performing the actions and services attributed above to
the merchant device 104. Functional
components stored in the computer-readable media 1906 can include the POS
application 106, which can include the
balance applet 1006, at least some of the functionalities of which are
described above. In other examples, the balance
applet 1006 can be stored in the computer-readable media 1906 independently or
associated with another application.
Further, in some examples, the balance applet 1006 can be accessible via a web
browser, etc.
[0184] Furthermore, the computer-readable media 1906 can include
additional functional components, such as
an operating system 1912 for controlling and managing various functions of the
merchant device 104 and for enabling
basic user interactions. In addition, the computer-readable media 1906 can
also store data, data structures and the
like, that are used by the functional components. Depending on the type of the
merchant device 104, the computer-
readable media 1906 can also optionally include other functional components
and data, such as other modules and
data 1914, which can include programs, drivers, etc., and the data used or
generated by the functional components.
Further, the merchant device 104 can include many other logical, programmatic
and physical components, of which
those described are merely examples that are related to the discussion herein.
[0185] The communication interface(s) 1908 can include one or more
interfaces and hardware components for
enabling communication with various other devices, such as over the network(s)
1902 or directly. For example,
communication interface(s) 1908 can enable communication through one or more
network(s) 1902, which can include,
33
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
but are not limited any type of network known in the art, such as a local area
network or a wide area network, such as
the Internet, and can include a wireless network, such as a cellular network,
a local wireless network, such as Wi-Fi
and/or close-range wireless communications, such as Bluetooth , BLE, NFC,
RFID, a wired network, or any other
such network, or any combination thereof. Accordingly, network(s) 1902 can
include both wired and/or wireless
communication technologies, including Bluetooth , BLE, Wi-Fi and cellular
communication technologies, as well as
wired or fiber optic technologies. Components used for such communications can
depend at least in part upon the
type of network, the environment selected, or both. Protocols for
communicating over such networks are well known
and will not be discussed herein in detail. of the Internet, cable networks,
cellular networks, wireless networks (e.g.,
Wi-Fi) and wired networks, as well as close-range communications such as
Bluetooth , Bluetooth low energy, and
the like, as additionally enumerated elsewhere herein.
[0186] The merchant device 104 can further include the one or more I/O
devices 1910. The I/O devices 1910 can
include speakers, a microphone, a camera, and various user controls (e.g.,
buttons, a joystick, a keyboard, a keypad,
etc.), a haptic output device, and so forth.
[0187] In at least one example, merchant device 104 can include a display
1916. Depending on the type of
computing device(s) used as the merchant device 104, the display 1916 can
employ any suitable display technology.
For example, the display 1916 can be a liquid crystal display, a plasma
display, a light emitting diode display, an OLED
(organic light-emitting diode) display, an electronic paper display, or any
other suitable type of display able to present
digital content thereon. In some examples, the display 1916 can have a touch
sensor associated with the display 1916
to provide a touchscreen display configured to receive touch inputs for
enabling interaction with a graphic interface
presented on the display 1916. Accordingly, implementations herein are not
limited to any particular display
technology. Alternatively, in some examples, the merchant device 104 may not
include the display 1916, and
information can be presented by other means, such as aurally.
[0188] In addition, the merchant device 104 can include sensor(s) 1918.
The sensor(s) 1918 can include a GPS
device able to indicate location information. Further, the sensor(s) 1918 can
include, but are not limited to, an
accelerometer, gyroscope, compass, proximity sensor, camera, microphone,
and/or a switch. Additionally, the
merchant device 104 can include various other components that are not shown,
examples of which include removable
storage, a power source, such as a battery and power control unit, a barcode
scanner, a printer, a cash drawer, and
so forth.
[0189] In addition, in some examples, the merchant device 104 can include
or can be connectable to a reader
device 704, as described above with reference to FIG. 7, for reading payment
instruments and/or identifiers associated
with payment objects. In some examples, as described above, the reader device
704 can plug in to a port in the
merchant device 104, such as a microphone/headphone port, a data port, or
other suitable port. The reader device
704 can include a read head for reading a magnetic strip of a payment card,
and further can include encryption
technology for encrypting the information read from the magnetic strip.
Additionally or alternatively, the reader device
704 can be an EMV payment reader, which in some examples, can be embedded in
the merchant device 104.
Moreover, numerous other types of readers can be employed with the merchant
device 104 herein, depending on the
type and configuration of the merchant device 104.
34
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0190] The server(s) 112 can include one or more servers or other types
of computing devices that can be
embodied in any number of ways. For example, in the example of a server, the
modules, other functional components,
and data can be implemented on a single server, a cluster of servers, a server
farm or data center, a cloud-hosted
computing service, a cloud-hosted storage service, and so forth, although
other computer architectures can
additionally or alternatively be used.
[0191] Further, while the figures illustrate the components and data of
the server(s) 112 as being present in a
single location, these components and data can alternatively be distributed
across different computing devices and
different locations in any manner. Consequently, the functions can be
implemented by one or more server computing
devices, with the various functionality described above distributed in various
ways across the different computing
devices. Multiple server(s) 112 can be located together or separately, and
organized, for example, as virtual servers,
server banks and/or server farms. The described functionality can be provided
by the servers of a single merchant or
enterprise, or can be provided by the servers and/or services of multiple
different customers or enterprises.
[0192] In the illustrated example, the server(s) 112 can include one or
more processors 1920, one or more
computer-readable media 1922, one or more communication interfaces 1924, and
one or more input/output devices
1926. Each processor 1920 can be a single processing unit or a number of
processing units, and can include single
or multiple computing units or multiple processing cores. The processor(s)
1920 can be implemented as one or more
microprocessors, microcomputers, microcontrollers, digital signal processors,
central processing units, state
machines, logic circuitries, and/or any devices that manipulate signals based
on operational instructions. For example,
the processor(s) 1920 can be one or more hardware processors and/or logic
circuits of any suitable type specifically
programmed or configured to execute the algorithms and processes described
herein. The processor(s) 1920 can be
configured to fetch and execute computer-readable instructions stored in the
computer-readable media 1922, which
can program the processor(s) 1920 to perform the functions described herein.
[0193] The computer-readable media 1922 can include volatile and
nonvolatile memory and/or removable and
non-removable media implemented in any type of technology for storage of
information, such as computer-readable
instructions, data structures, program modules, or other data. Such computer-
readable media 1922 can include, but
is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology,
optical storage, solid state storage,
magnetic tape, magnetic disk storage, RAID storage systems, storage arrays,
network attached storage, storage area
networks, cloud storage, or any other medium that can be used to store the
desired information and that can be
accessed by a computing device. Depending on the configuration of the
server(s) 112, the computer-readable media
1922 can be a type of computer-readable storage media and/or can be a tangible
non-transitory media to the extent
that when mentioned, non-transitory computer-readable media exclude media such
as energy, carrier signals,
electromagnetic waves, and signals per se.
[0194] The computer-readable media 1922 can be used to store any number
of functional components that are
executable by the processors 1920. In many implementations, these functional
components comprise instructions or
programs that are executable by the processors 1920 and that, when executed,
specifically configure the one or more
processors 1920 to perform the actions attributed above to the service
provider and/or payment processing service.
Functional components stored in the computer-readable media 1922 can include
the merchant module 114, the set-
up module 116, the balance management module 118, and the activation module
702. At least some of the
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
functionality associated with the merchant module 114, the set-up module 116,
the balance management module 118,
and the activation module 702 is described above with reference to FIGS. 1-18.
Additional functional components
stored in the computer-readable media 1922 can include an operating system
1928 for controlling and managing
various functions of the server(s) 112.
[0195] In at least one example, the computer-readable media 1922 can
include or maintain other functional
components and data, such as other modules and data 1930, which can include
programs, drivers, etc., and the data
used or generated by the functional components. Further, the server(s) 112 can
include many other logical,
programmatic and physical components, of which those described above are
merely examples that are related to the
discussion herein.
[0196] In at least one example, the computer-readable media 1922 can store
a merchant database 1932. The
merchant database 1932 can store merchant profiles corresponding to merchants
that subscribe to services of the
payment processing service. As described above, merchant profiles can include
merchant data including, but not
limited to, a merchant category classification (MCC), item(s) offered for sale
by the merchant, transaction data
associated with transactions conducted by the merchant (e.g., via the POS
application 106), hardware (e.g., device
type) used by the merchant, previous loans made to the merchant, previous
defaults on said loans, an indication of
risk (e.g., based at least in part on fraud, chargeback, etc.) associated with
the merchant, etc. The merchant profile
can securely store bank account information as provided by the merchant 102.
Further, the merchant profile can store
payment data associated with a payment instrument linked to a stored balance
120 of the merchant 102 and/or the
stored balance 120.
[0197] The communication interface(s) 1924 can include one or more
interfaces and hardware components for
enabling communication with various other devices, such as over the network(s)
19002. For example, communication
interface(s) 1924 can enable communication through one or more of the
Internet, cable networks, cellular networks,
wireless networks (e.g., Wi-Fi) and wired networks, as well as close-range
communications such as Bluetooth , BLE,
and the like, as additionally enumerated elsewhere herein.
[0198] The server(s) 112 can further be equipped with various input/output
(I/O) devices 1926. Such I/O devices
1926 can include a display, various user interface controls (e.g., buttons,
joystick, keyboard, mouse, touch screen,
etc.), audio speakers, connection ports and so forth.
[0199] The present subject matter proposes the integration of at least
the aforementioned features into a seamless
and convenient mechanism for registration of a payment instrument. With
relation to the problems identified previously
with conventional systems and methods, the software application itself becomes
an active and cooperative component
of the registration process, rather than the subject of it. Further, the
aforementioned description is directed to devices
and applications that are related to payment technology. However, it will be
understood, that the technology can be
extended to any device and application. Moreover, techniques described herein
can be configured to operate
irrespective of the kind of payment object reader, POS terminal, web
applications, mobile applications, POS topologies,
payment cards, computer networks, and environments. Techniques described
herein can be configured to operate in
both real-time/online and offline modes.
[0200] While the aforementioned disclosure makes reference to user
interactions via a Ul presented via a display
of a device, the Ul can be presented via any input/output device. As an
example, the Ul can be output via a speaker,
36
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
and augmented reality projector, etc. Further, while the aforementioned
disclosure makes reference to the merchant
interacting with the Ul via a selectable control, in additional or alternative
examples, the merchant can indicate a
selection via a spoken input or other type of input.
[0201] The foregoing is merely illustrative of the principles of this
disclosure and various modifications can be
made by those skilled in the art without departing from the scope of this
disclosure. The above described examples
are presented for purposes of illustration and not of limitation. The present
disclosure also can take many forms other
than those explicitly described herein. Accordingly, it is emphasized that
this disclosure is not limited to the explicitly
disclosed methods, systems, and apparatuses, but is intended to include
variations to and modifications thereof, which
are within the spirit of the following claims.
[0202] As a further example, variations of apparatus or process limitations
(e.g., dimensions, configurations,
components, process step order, etc.) can be made to further optimize the
provided structures, devices and methods,
as shown and described herein. In any event, the structures and devices, as
well as the associated methods,
described herein have many applications. Therefore, the disclosed subject
matter should not be limited to any single
example described herein, but rather should be construed in breadth and scope
in accordance with the appended
claims.
EXAMPLE CLAUSES
[0203] A: A method implemented in part by a server of a payment
processing service, the method comprising:
receiving, from a point-of-sale (POS) application associated with a merchant
device of a merchant, transaction data
associated with POS transactions between the merchant and customers, wherein
the POS application configures the
merchant device as a POS terminal for determining and transmitting the
transaction data to the payment processing
service via a network; determining an amount of funds owed to the merchant
based on the transaction data; and
associating the amount of funds with a stored balance maintained in a ledger
of the payment processing service,
wherein the stored balance is accessible via multiple withdrawal channels
comprising: (i) a physical payment
instrument associated with the stored balance, wherein the physical payment
instrument enables the merchant to
access the stored balance substantially immediately after funding a POS
transaction at the POS; (ii) an instant deposit
of the stored balance into the linked bank account of the merchant, wherein
the instant deposit is made responsive to
a request to deposit the stored balance into the linked bank account after the
funding of the transaction; and (iii) a
scheduled deposit of the stored balance into a linked bank account associated
with the merchant, wherein the
scheduled deposit occurs at a prearranged time after the funding of the
transaction at the POS.
[0204] B: The method as clause A recites, further comprising: receiving
additional transaction data associated
with transactions between the merchant and other merchants; analyzing the
additional transaction data to identify
business transactions and personal transactions; and adding indicators to the
ledger to identify the business
transactions and the personal transactions.
[0205] C: The method as clause A or B recites, wherein a default
withdrawal channel is the scheduled deposit.
[0206] D: The method as clause C recites, further comprising, responsive to
activating the physical payment
instrument, disabling, at least temporarily, the scheduled deposit withdrawal
channel and setting the physical payment
instrument as the default withdrawal channel.
37
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0207] E: The method as any of clauses A¨D recites, further comprising:
receiving, from the merchant device, an
instruction to withhold a portion of total funds owed to the merchant for
another purpose; and withholding the portion
of the total funds from the account of the merchant, wherein the amount of
funds is substantially equal to the total
funds less the portion of the total funds.
[0208] F: The method as any of clauses A¨E recites, wherein the stored
balance is managed via a balance applet
executable by the merchant device, and the method further comprises:
receiving, via the POS application, the payment
data at a time after activation of the physical payment instrument;
determining that the payment data is associated
with the physical payment instrument of the merchant and is received
independent of a POS transaction; and causing,
based on receiving the payment data, a user interface associated with the
balance applet to be presented via a display
of the merchant device to enable the merchant to manage the stored balance.
[0209] G: A system comprising: one or more processors; one or more
computer-readable media that, when
executed by the one or more processors, cause the one or more processors to
perform operations comprising:
determining, based on funds received from point-of-sale (Pos) transactions
processed via a payment processing
service on behalf of a merchant, a stored balance that is to be maintained in
a ledger of the payment processing
service; and associating the stored balance with a payment instrument of the
merchant, wherein the stored balance is
accessible via the payment instrument substantially immediately after funding
of a transaction at the POS and via (i)
an instant deposit to a linked bank account of the merchant and (ii) a
scheduled deposit to the linked bank account,
wherein the instant deposit is available substantially immediately after
funding of the transaction and the scheduled
deposit is made at a prearranged time after the funding of the transaction.
[0210] H: The system as clause G recites, wherein a default withdrawal
channel associated with the stored
balance is the scheduled deposit and, responsive to activating the payment
instrument, the operations further comprise
temporarily disabling the scheduled deposit.
[0211] I: The system as clause G or H recites, wherein the stored balance
is further accessible to the merchant
for transferring funds associated with the stored balance to a bank account of
an employee of the merchant or a vendor
from which the merchant acquires inventory items or supplies.
[0212] J: The system as any of clauses G¨I recites, the operations
further comprising: receiving an instruction to
withhold a first portion of total funds owed to the merchant for saving;
adding the first portion of the total funds to
another stored balance associated with the merchant; and adding a second
portion of the total funds to the stored
balance.
[0213] K: The system as any of clauses G¨J recites, the operations further
comprising: receiving additional
transaction data associated with one or more transactions between the merchant
and other merchants; analyzing the
additional transaction data to classify the one or more transactions as a
business transaction or a personal transaction;
and adding one or more indicators to the ledger based on classifications of
the one or more transactions.
[0214] L: The system as clause K recites, the operations further
comprising causing a user interface (UI)
associated with the stored balance to be presented via a display of the
merchant device, wherein the Ul presents at
least a portion of the ledger and an individual transaction of the one or more
transactions is associated with (i) an
indicator of a classification of the individual transaction and (ii) a
selectable control that, when selected causes the
classification to be modified.
38
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0215] M: The system as any of clauses G¨L recites, the operations
further comprising: receiving additional
transaction data associated with one or more transactions between the merchant
and other merchants; and
associating an electronic record of an individual transaction with an
indication of the individual transaction in the ledger.
[0216] N: The system as clause M recites, the operations further
comprising causing a user interface (UI)
associated with the stored balance to be presented via a display of the
merchant device, wherein the UI presents at
least a portion of the ledger and the indication of the individual transaction
in the ledger is associated with a selectable
control that, when selected causes the electronic record to be presented.
[0217] 0: The system as any of clauses G¨N recites, the operations
further comprising causing a user interface
(UI) associated with the stored balance to be presented via a display of the
merchant device responsive to receiving
an indication of an interaction between the payment instrument and a payment
reader associated with the merchant
device.
[0218] P: The system as any of clauses G-0 recites, the operations
further comprising: receiving a request to
access a user interface (UI) associated with the stored balance; determining
an identification of a user associated with
the request; determining, based on one or more permissions, that the user is
permitted to access the UI; and causing
the UI to be presented via a display of the merchant device.
[0219] Q: One or more computer-readable media that, when executed by one
or more processors, cause the one
or more processors to perform operations comprising: determining, based on
funds received from point-of-sale (Pos)
transactions processed via a payment processing service on behalf of a
merchant, a stored balance that is maintained
in a ledger of the payment processing service; and associating the stored
balance with a payment instrument of the
merchant, wherein the stored balance is accessible via the payment instrument
substantially immediately after funding
of a transaction at the POS and via (i) an instant deposit to a linked bank
account of the merchant and (ii) a scheduled
deposit to the linked bank account, wherein the instant deposit is available
substantially immediately after funding of
the transaction and the scheduled deposit is made at a prearranged time after
the funding of the transaction.
[0220] R: The one or more computer-readable media as clause Q recites,
wherein a default withdrawal channel
associated with the stored balance is the scheduled deposit and, responsive to
activating the payment instrument, the
operations further comprise temporarily disabling the scheduled deposit.
[0221] S: The one or more computer-readable media as clause R recites,
wherein the payment instrument is
activated responsive to an interaction between the payment instrument and a
payment reader at a merchant device
of the merchant.
[0222] T: The one or more computer-readable media as any of clauses Q¨S
recites, the operations further
comprising causing a user interface (UI) associated with the stored balance to
be presented via a display of the
merchant device, wherein the UI presents at least a portion of the ledger and
an individual transaction in the ledger is
associated with a selectable control that enables the merchant to manage the
individual transaction.
[0223] U: A method implemented in part by a server of a payment
processing service, the method comprising:
receiving, at the server and from a point-of-sale (POS) application associated
with a merchant device of a merchant,
a request for a payment card that is to be associated with an account of the
merchant that is maintained in a ledger of
the payment processing service, the account having a stored balance that is
funded with funds received from POS
transactions processed via the payment processing service; receiving, via a
user interface (UI) of the POS application,
39
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
a request to activate the payment card, the payment card having been received
by the merchant; prompting, via the
Ul of the POS application, the merchant to insert the payment card into a
payment reader associated with the merchant
device; receiving, by the server, payment data associated with the payment
card, the payment data obtained by the
payment reader and transmitted from the POS application to the server;
comparing, by the server, the payment data
with known payment data of the payment card that was provided to the merchant;
determining, by the server, that the
payment data corresponds to the known payment data; and activating, by the
server, the payment card to enable the
merchant to use the payment card for accessing the stored balance of the
account.
[0224] V: The method as clause U recites, further comprising modifying a
deposit scheme based at least in part
on activation of the payment card, wherein modifying the deposit scheme
comprises freezing transfers of funds from
the account to a linked bank account of the merchant in order to retain the
funds in the account.
[0225] W: The method as clause U or V recites, wherein, responsive to
receiving the request for the payment
card, the method further comprises: sending, from the server and to the POS
application, icons for personalizing a
surface of the payment card; and arranging the icons in an order based on a
classification of the merchant.
[0226] X: The method as clause W recites, wherein arranging the icons in
the order comprises arranging a first
icon that is relevant to the classification of the merchant prior to a second
icon that is not relevant to the classification
of the merchant.
[0227] Y: The method as clause W or X recites, further comprising:
presenting, via the Ul of the POS application,
at least a portion of the icons for selection by the merchant; sending, by the
POS application, an indication of a selection
of an icon of the icons to the server; receiving, by the server, the
indication of the selection; and sending, by the server,
an instruction to an embossing device to emboss the icon on the surface of the
payment card prior to providing the
payment card to the merchant.
[0228] Z: A system comprising: one or more processors; one or more
computer-readable media that, when
executed by the one or more processors, cause the one or more processors to
perform acts comprising: receiving,
from a point-of-sale (POS) application associated with a merchant device of a
merchant, a request for a payment
instrument that is to be associated with an account of the merchant, the
account being maintained in a ledger of a
payment processing service; receiving, via a user interface (UI) of the POS
application, a request to activate the
payment instrument, the payment instrument having been received by the
merchant; prompting, via the Ul of the POS
application, the merchant to cause an interaction between the payment
instrument and a payment reader associated
with the merchant device; receiving payment data associated with the payment
instrument, the payment data obtained
by the payment reader; determining that the payment data corresponds to known
payment data associated with the
payment instrument; and activating the payment instrument to enable the
merchant to use the payment instrument for
accessing the account.
[0229] AA: The system as clause Z recites, wherein the account is
associated with a stored balance that is funded
at least in part with funds received from POS transactions processed via the
payment processing service.
[0230] AB: The system as clause Z or AA recites, wherein the interaction is
a dip, a tap, or a swipe.
[0231] AC: The system as any of clauses Z¨AB recites, the acts further
comprising: receiving, at a server
associated with the payment processing service, from the POS application, the
payment data; comparing, by the
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
server, the payment data with the known payment data; and activating, by the
server, the payment instrument
responsive to the payment data corresponding to the known payment data.
[0232] AD: The system as any of clauses Z¨AC recites, the acts further
comprising: receiving, at the POS
application and from a server associated with the payment processing service,
the known payment data; comparing,
by the POS application, the payment data with the known payment data;
activating, by the POS application, the
payment instrument responsive to the payment data corresponding to the known
payment data; and sending an
indication that the payment instrument is activated to the server associated
with the payment processing service.
[0233] AE: The system as any of clauses Z¨AD recites, the acts further
comprising modifying a deposit scheme
based at least in part on activation of the payment instrument.
[0234] AF: The system as any of clauses Z¨AE recites, the acts further
comprising: responsive to receiving the
request for the payment instrument, presenting one or more icons for
personalizing a surface of the payment
instrument via the Ul of the POS application, the one or more icons arranged
in an order based on a classification of
the merchant; receiving, via the Ul of the POS application, a selection of at
least one icon; and sending an instruction
to associate the at least one icon with the surface of the payment instrument
prior to providing the payment instrument
to the merchant.
[0235] AG: The system as any of clauses Z¨AF recites, the acts further
comprising: receiving, via the POS
application, the payment data at a time after activation of the payment
instrument; determining that the payment data
is associated with the payment instrument of the merchant and is received
independent of a transaction; and causing,
based on receiving the payment data, an applet for managing the account of the
merchant to be opened on the
merchant device.
[0236] AH: The system as any of clauses Z¨AG recites, the acts further
comprising: receiving, via the Ul of the
POS application, a request to deactivate or freeze the payment instrument;
prompting, via the Ul of the POS
application, the merchant to cause another interaction between the payment
instrument and the payment reader;
receiving, via the POS application, the payment data responsive to the other
interaction between the payment
instrument and the payment reader; and deactivating or freezing the payment
instrument.
[0237] Al: One or more computer-readable media that, when executed by one
or more processors, cause the one
or more processors to perform acts comprising: receiving a request for a
payment instrument that is to be associated
with an account of a merchant, the account being maintained in a ledger of a
payment processing service; receiving
a request to activate the payment instrument, the payment instrument having
been received by the merchant;
prompting the merchant to cause an interaction between the payment instrument
and a payment reader associated
with a merchant device of the merchant; receiving payment data associated with
the payment instrument, the payment
data obtained by the payment reader; determining that the payment data
corresponds to known payment data
associated with the payment instrument; and activating the payment instrument
to enable the merchant to use the
payment instrument for accessing the account.
[0238] AJ: The one or more computer-readable media as clause Al recites,
wherein the account is associated
with a stored balance that is funded at least in part with funds received from
POS transactions processed via the
payment processing service.
41
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0239] AK: The one or more computer-readable media as clause Al or AJ
recites, wherein a server associated
with the payment processing service or a point-of-sale (Pos) application
associated with the merchant device activates
the payment instrument responsive to determining that the payment data
corresponding to the known payment data.
[0240] AL: The one or more computer-readable media as any of clauses
Al¨AK recites, the acts further
comprising, responsive to activating the payment instrument, freezing a
transfer of funds from the account to a linked
bank account of the merchant in order to retain the funds in the account.
[0241] AM: The one or more computer-readable media as any of clauses
Al¨AL recites, the acts further
comprising: responsive to receiving the request for the payment instrument,
presenting one or more icons for
personalizing a surface of the payment instrument via the Ul of the POS
application, the one or more icons arranged
in an order based on a classification of the merchant; receiving, via the Ul
of the POS application, a selection of at
least one icon; and sending an instruction to associate the at least one icon
with the surface of the payment instrument
prior to providing the payment instrument to the merchant.
[0242] AN: The one or more computer-readable media as any of clauses
Al¨AM recites, the acts further
comprising: receiving, via the POS application, the payment data at a time
after activation of the payment instrument;
determining that the payment data is associated with the payment instrument of
the merchant and is received
independent of a transaction; and causing, based on receiving the payment
data, an applet for managing the account
of the merchant to be opened on the merchant device.
[0243] AO: A method implemented in part by a server of a payment
processing service, the method comprising:
receiving, from a payment network or an issuer, an authorization request to
authorize a payment instrument for a
predicted cost of a transaction between a first merchant and a second
merchant, wherein the payment instrument is
associated with a first merchant and a stored balance maintained in a ledger
of the payment processing service, the
stored balance generated from funds obtained from POS transactions processed
by the payment processing service
on behalf of the first merchant; comparing the predicted cost of the
transaction with the stored balance; determining
that the stored balance is less than the predicted cost of the transaction;
determining that the payment instrument is
not authorized for the predicted cost of the transaction based on determining
that the stored balance is less than the
predicted cost of the transaction; determining that an actual cost of the
transaction is likely to be less than the amount
of the stored balance; and instead of declining the transaction, sending an
indication that the payment instrument is
approved for the predicted cost of the transaction to the payment network or
the issuer.
[0244] AP: A method as clause AO recites, wherein determining that the
actual cost of the transaction is likely to
be less than the amount of the stored balance is based at least in part on
historical transaction data indicative of
previous transactions between the first merchant and other merchants similar
to the second merchant.
[0245] AQ: A method as clause AO or AP recites, wherein determining that
the actual cost of the transaction is
likely to be less than the amount of the stored balance is based at least in
part on historical transaction data indicative
of previous transactions similar to the transaction.
[0246] AR: A system comprising: one or more processors: one or more
computer-readable media that, when
executed by the one or more processors, cause the one or more processors to
perform operations comprising:
receiving an authorization request to authorize a payment instrument for a
predicted cost of a transaction between a
first user and a second user; comparing the predicted cost of the transaction
with an available balance of the payment
42
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
instrument; determining that the available balance is less than the predicted
cost of the transaction; determining that
the payment instrument is not authorized for the predicted cost of the
transaction based on determining that the
available balance is less than the predicted cost of the transaction; and
authorizing the transaction, instead of declining
the transaction, based at least in part on a prediction of the actual cost of
the transaction.
[0247] AS: The system as clause AR recites, wherein the authorization
request is received from a payment
network or an issuer of the payment instrument.
[0248] AT: The system as clause AS recites, wherein at least one of the
payment network or the issuer is a
payment processing service associated with the system.
[0249] AU: The system as clause AS or AT recites, the operations further
comprising sending an indication that
the payment instrument is approved for the predicted cost of the transaction
to the payment network or the issuer.
[0250] AV: The system as any of clauses AR¨AU recites, wherein the
payment instrument is associated with a
merchant and the available balance is a stored balance maintained in a ledger
of a payment processing service, the
stored balance generated from funds obtained from point-of-sale (Pos)
transactions processed by the payment
processing service on behalf of the first user.
[0251] AW: The system as any of clauses AR¨AV recites, the operations
further comprising: accessing transaction
data associated with previous transactions between the first user and one or
more other users; and predicting the
actual cost of the transaction based at least in part on a cost of a previous
transaction of the one or more previous
transactions between another user that is similar to the second user.
[0252] AX: The system as any of clauses AR¨AW recites, the operations
further comprising: accessing transaction
data associated with previous transactions between the first user and one or
more other users; and predicting the
actual cost of the transaction based at least in part on a cost of a previous
transaction of the one or more previous
transactions that is similar to the transaction.
[0253] AY: The system as any of clauses AR¨AX recites, the operations
further comprising: determining that the
actual cost is likely to be less than the amount of the available balance; and
authorizing the transaction instead of
declining the transaction.
[0254] AZ: The system as any of clauses AR¨AY recites, the operations
further comprising: determining that the
actual cost is more than the amount of the available balance; responsive to
receiving a capture request, authorizing
the transaction instead of declining the transaction; determining a difference
between the actual cost and the available
balance; and repaying the difference between the actual cost and the available
balance based on funds obtained from
point-of-sale (POS) transactions processed by the payment processing service
on behalf of the first user at a time
after the transaction.
[0255] BA: The system as any of clauses AR¨AZ recites, the operations
further comprising: determining that the
actual cost is likely to be more than the amount of the available balance;
determining a difference between the actual
cost and the available balance; sending a capital offer in an amount at least
equal to the difference to the first user,
the capital offer being provided by the payment processing service; receiving
an indication that the first user accepts
the capital offer; initiating a capital loan based on acceptance of the
capital offer; and authorizing the transaction
instead of declining the transaction based on initiating the capital loan
offer.
43
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
[0256] BB: One or more computer-readable media that, when executed by the
one or more processors, cause the
one or more processors to perform operations comprising: receiving an
authorization request to authorize a payment
instrument for a predicted cost of a transaction between a first user and a
second user; comparing the predicted cost
of the transaction with an available balance of the payment instrument;
determining that the available balance is less
than the predicted cost of the transaction; determining that the payment
instrument is not authorized for the predicted
cost of the transaction based on determining that the available balance is
less than the predicted cost of the
transaction; and authorizing the transaction instead of declining the
transaction based at least in part on a prediction
of the actual cost of the transaction.
[0257] BC: The one or more computer-readable media as clause BB recites,
wherein the authorization request is
received from a payment network or an issuer of the payment instrument and the
operations further comprise sending
an indication that the payment instrument is approved for the predicted cost
of the transaction to the payment network
or the issuer.
[0258] BD: The one or more computer-readable media as clause BB or BC
recites, wherein the payment
instrument is associated with a merchant and the available balance is a stored
balance maintained in a ledger of a
payment processing service, the stored balance generated from funds obtained
from point-of-sale (POS) transactions
processed by the payment processing service on behalf of the first user.
[0259] BE: The one or more computer-readable media as any of clauses
BB¨BD recites, the operations further
comprising: determining that the actual cost is likely to be less than the
amount of the available balance; and
authorizing the transaction instead of declining the transaction.
[0260] BF: The one or more computer-readable media as any of clauses BB¨BE
recites, the operations further
comprising: determining that the actual cost is likely to be more than the
amount of the available balance; authorizing
the transaction instead of declining the transaction; determining a difference
between the actual cost and the available
balance; and repaying the difference between the actual cost and the available
balance based on funds obtained from
point-of-sale (POS) transactions processed by the payment processing service
on behalf of the first user at a time
after the transaction.
[0261] BG: The one or more computer-readable media as any of clauses
BB¨BF recites, the operations further
comprising: determining that the actual cost is likely to be more than the
amount of the available balance; determining
a difference between the actual cost and the available balance; sending a
capital offer in an amount at least equal to
the difference to the first user, the capital offer being provided by the
payment processing service; receiving an
indication that the first user accepts the capital offer; initiating a capital
loan based on acceptance of the capital offer;
and authorizing the transaction instead of declining the transaction based on
initiating the capital loan offer.
[0262] BH: The one or more computer-readable media as any of clauses
BB¨BG recites, the operations further
comprising: accessing transaction data associated with previous transactions
between the first user and one or more
other users; and predicting the actual cost of the transaction based at least
in part on a cost of a previous transaction
of the one or more previous transactions that shares a characteristic with at
least one of (i) the transaction or (ii) the
second user.
[0263] BI: A method implemented in part by a server of a payment
processing service, the method comprising:
receiving, at the server of the payment processing service and from a point-of-
sale (POS) application associated with
44
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
a merchant device of a merchant, transaction data associated with POS
transactions between the merchant and
customers, wherein the POS application configures the merchant device as a POS
terminal for determining and
transmitting the transaction data to the payment processing service via a
network; determining, by the server of the
payment processing service, an amount of funds owed to the merchant based on
the transaction data; associating, by
the server of the payment processing service, the amount of funds with a
stored balance maintained by the payment
processing service; associating, by the server of the payment processing
service, a physical payment instrument with
the stored balance, wherein a portion of the stored balance that is
attributable to a POS transaction of POS transactions
is accessible via the physical payment instrument substantially immediately
after the POS transaction; and transferring,
by the server of the payment processing service, at least the portion of the
stored balance into a linked bank account
of the merchant via at least one of: (i) an instant deposit that is made
substantially immediately after the POS
transaction; or (ii) a scheduled deposit that is made at a prearranged time
after the POS transaction.
[0264] BJ: The method as clause BI recites, further comprising: receiving
additional transaction data associated
with transactions between the merchant and other merchants; analyzing the
additional transaction data to identify
business transactions and personal transactions; and adding indicators to a
ledger associated with the stored balance
to identify the business transactions and the personal transactions.
[0265] BK: The method as clause BI or BJ recites, wherein a default
withdrawal channel is the scheduled deposit.
[0266] BL: The method as clause BK recites, further comprising,
responsive to activating the physical payment
instrument, disabling, at least temporarily, scheduled deposits and setting
the physical payment instrument as the
default withdrawal channel.
[0267] BM: The method as any of clauses BI¨BL recites, further comprising:
receiving, from the merchant device,
an instruction to withhold an additional portion of total funds owed to the
merchant for another purpose; and withholding
the additional portion of the total funds from the stored balance of the
merchant.
[0268] BN: The method as any of clauses BI¨BM recites, wherein the stored
balance is managed via a balance
applet executable by the merchant device, and the method further comprises:
receiving, via the POS application,
payment data associated with the physical payment instrument at a time after
activation of the physical payment
instrument; determining that the payment data is associated with the physical
payment instrument of the merchant
and is received independent of another POS transaction; and causing, based on
receiving the payment data, a user
interface associated with the balance applet to be presented via a display of
the merchant device to enable the
merchant to manage the stored balance.
[0269] BO: A system comprising: one or more processors; one or more
computer-readable media that, when
executed by the one or more processors, cause the one or more processors to
perform operations comprising:
determining, based on point-of-sale (POS) transactions processed via a payment
processing service on behalf of a
merchant, a stored balance that is to be maintained by the payment processing
service; associating the stored balance
with a payment instrument of the merchant, wherein at least a first portion of
the stored balance that is attributable to
a POS transaction of the POS transactions is accessible via the payment
instrument substantially immediately after
the POS transaction; and transferring at least the first portion of the stored
balance into a linked bank account of the
merchant via at least one of: (i) an instant deposit; or (ii) a scheduled
deposit, wherein the instant deposit is made
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
substantially immediately after the POS transaction and the scheduled deposit
is made at a prearranged time after the
POS transaction.
[0270] BP: The system as clause BO recites, wherein a default withdrawal
channel associated with the stored
balance is the scheduled deposit and, responsive to activating the payment
instrument, the operations further comprise
temporarily disabling the scheduled deposit.
[0271] BQ: The system as clause BO or BP recites, wherein at least a
second portion of the stored balance is
further accessible to the merchant for transferring the second portion of the
stored balance to a bank account of an
employee of the merchant or a vendor from which the merchant acquires
inventory items or supplies.
[0272] BR: The system as any of clauses BO¨BQ recites, wherein the
instant deposit is made after the merchant
instructs the payment processing service to make the instant deposit.
[0273] BS: The system as any of clauses BO¨BR recites, the operations
further comprising: receiving additional
transaction data associated with one or more additional POS transactions
between the merchant and other merchants;
analyzing the additional transaction data to classify the one or more
additional POS transactions as a business
transaction or a personal transaction; and adding one or more indicators to a
ledger associated with the stored balance
based on classifications of the one or more additional POS transactions.
[0274] BT: The system as clause BS recites, the operations further
comprising causing a user interface (UI)
associated with the stored balance to be presented via a display of a device
operable by the merchant, wherein the
UI presents at least a portion of the ledger and an individual POS transaction
of the one or more additional POS
transactions is associated with (i) an indicator of a classification of the
individual POS transaction and (ii) a selectable
control that, when selected causes the classification to be modified.
[0275] BU: The system as any of clauses BO¨BT recites, the operations
further comprising: receiving additional
transaction data associated with one or more additional POS transactions
between the merchant and other merchants;
and associating an electronic record of an individual POS transaction with an
indication of the individual POS
transaction in a ledger associated with the stored balance.
[0276] BV: The system as clause BU recites, the operations further
comprising causing a user interface (UI)
associated with the stored balance to be presented via a display of a device
operable by the merchant, wherein the
UI presents at least a portion of the ledger and the indication of the
individual POS transaction in the ledger is
associated with a selectable control that, when selected causes the electronic
record to be presented.
[0277] BW: The system as any of clauses BO¨BV recites, the operations
further comprising causing a user
interface (UI) associated with the stored balance to be presented via a
display of a device operable by the merchant
responsive to receiving an indication of an interaction between the payment
instrument and a payment reader
associated with the device.
[0278] BX: The system as any of clauses BO¨BW recites, the operations
further comprising: receiving a request
to access a user interface (UI) associated with the stored balance;
determining an identification of a user associated
with the request; determining, based on one or more permissions, that the user
is permitted to access the UI; and
causing the UI to be presented via a display of a device operable by the
merchant.
[0279] BY: One or more non-transitory computer-readable media that, when
executed by one or more processors,
cause the one or more processors to perform operations comprising:
determining, based on point-of-sale (Pos)
46
CA 03111997 2021-03-05
WO 2020/068405
PCT/US2019/050250
transactions processed via a payment processing service on behalf of a
merchant, a stored balance that is maintained
by the payment processing service; associating the stored balance with a
payment instrument of the merchant, wherein
at least a portion of the stored balance that is attributable to a POS
transaction of the POS transactions is accessible
via the payment instrument substantially immediately after the POS
transaction; and transferring at least the portion
of the stored balance into a linked bank account of the merchant via at least
one of: (i) an instant deposit; or (ii) a
scheduled deposit, wherein the instant deposit is made substantially
immediately after the POS transaction and the
scheduled deposit is made at a prearranged time after the POS transaction.
[0280] BZ: The one or more non-transitory computer-readable media as
clause BY recites, wherein a default
withdrawal channel associated with the stored balance is the scheduled deposit
and, responsive to activating the
.. payment instrument, the operations further comprise temporarily disabling
the scheduled deposit.
[0281] CA: The one or more non-transitory computer-readable media as
clause BZ recites, wherein the payment
instrument is activated responsive to an interaction between the payment
instrument and a payment reader at a
merchant device of the merchant.
[0282] CB: The one or more non-transitory computer-readable media as any
of clauses BY¨CA recites, the
operations further comprising causing a user interface (UI) associated with
the stored balance to be presented via a
display of a device operable by the merchant, wherein the Ul presents at least
a portion of a ledger associated with
the stored balance and an individual POS transaction in the ledger is
associated with a selectable control that enables
the merchant to manage the individual POS transaction.
47
