Permission management via mobile payment application
Permission management via a mobile payment application is described. A first request to authorize an account of a customer for payment a transaction between the customer and a third-party merchant can be received from a third-party application. Based on the first request indicating that the third-party merchant is permitted to store payment data associated with the account of the customer for processing payment(s) for future transaction(s), a token can be sent to the third-party merchant to be stored for processing the payment(s) for the future transaction(s). A user interface presented via an instance of a mobile payment application, associated with the payment service, on a computing device of the customer, can enable the customer to manage permission(s) associated with the token. A permission associated with the token can be modified based at least in part on receiving a second request via the mobile payment application.
1 . A method, implemented by at least one server of a payment service, comprising:
receiving, from a third-party application associated with a third-party merchant, a first request to authorize an account of a customer for payment of at least a transaction between the customer and the third-party merchant;
sending, to the third-party application and based at least in part on the first request indicating that the third-party merchant is permitted to store payment data associated with the account of the customer for processing one or more payments for one or more future transactions, a token to be stored for processing the one or more payments for the one or more future transactions, wherein invoking the token for the one or more future transactions causes a mobile payment application to execute in the background and initiates a communication session between the third-party application and the mobile payment application for automatic payment without the customer having to provide the payment data in association with the one or more future transactions;
causing a user interface to be presented via an instance of the mobile payment application, associated with the payment service, on a computing device of the customer, wherein the user interface includes interactive elements selectable to enable the customer to:
manage one or more first permissions associated with the token;
manage one or more second permissions associated with payment requests from one or more other requesting applications; and
track a plurality of transactions associated with the mobile payment application, wherein the plurality of transactions includes the one or more future transactions and one or more other transactions conducted via at least one of the one or more other requesting applications;
receiving, from the computing device of the customer and via an interaction with the user interface, a second request to modify a first permission of the one or more first permissions associated with the token; and
based at least in part on the second request, causing the first permission associated with the token to be modified via a component of the mobile payment application that tracks the one or more first permissions and the one or more second permissions.
2 . The method as claim 1 recites, further comprising prior to receiving the first request, and based at least in part on detecting a selection of a payment field associated with the mobile payment application, causing a prompt for confirmation to process the payment for the transaction via the mobile payment application to be presented via the instance of the mobile payment application, wherein the first request is received in association with a response to the prompt.
3 . The method as claim 1 recites, further comprising:
based at least in part on receiving the first request, determining whether the account of the customer is authorized for the payment of the transaction; and
causing an indication of whether the payment is authorized or denied to be provided to the third-party application via the instance of the mobile payment application.
4 . The method as claim 1 recites, wherein the first request is associated with at least one of a device identifier associated with the computing device of the customer, a mobile payment application instance identifier associated with the instance of the mobile payment application, or a communication identifier, the method further comprising identifying the account based at least in part on at least one of the device identifier, the mobile payment application instance identifier, or the communication identifier.
5 . The method as claim 1 recites, wherein the user interface further enables the customer to manage a setting associated with the third-party application.
6 . The method as claim 1 recites, wherein the first request is associated with a first time, the method further comprising:
receiving, at a second time, from the third-party application, and based at least in part on the token having been sent to the third-party application, a third request to authorize the account of a customer for another payment for another transaction between the customer and the third-party merchant;
based at least in part on receiving the third request, determining whether the account of the customer is authorized for the other payment of the other transaction; and
causing another indication of whether the other payment is authorized or denied to be provided to the third-party application via the instance of the mobile payment application.
7 . The method as claim 1 recites, wherein modifying the first permission associated with the token comprises revoking use of the token by the third-party application.
8 . The method as claim 1 recites, wherein modifying the first permission associated with the token comprises invalidating the token.
9 . A system associated with a payment service, the system comprising:
one or more processors; and
one or more computer-readable media storing instructions that, when executed by the one or more processors, cause the system to perform operations comprising:
receiving, from a third-party application associated with a third-party merchant, a first request to authorize an account of a customer for payment of at least a transaction between the customer and the third-party merchant;
sending, to the third-party application and based at least in part on the first request indicating that the third-party merchant is permitted to store payment data associated with the account of the customer for processing one or more payments for one or more future transactions, a token to be stored for processing the one or more payments for the one or more future transactions, wherein invoking the token for the one or more future transactions causes a mobile payment application to execute in the background and initiates a communication session between the third-party application and the mobile payment application for automatic payment without the customer having to provide the payment data in association with the one or more future transactions;
causing a user interface to be presented via an instance of the mobile payment application, associated with the payment service, on a computing device of the customer, wherein the user interface includes interactive elements selectable to enable the customer to:
manage one or more first permissions associated with the token;
manage one or more second permissions associated with payment requests from one or more other requesting applications; and
track a plurality of transactions associated with the mobile payment application, wherein the plurality of transactions includes the one or more future transactions and one or more other transactions conducted via at least one of the one or more other requesting applications;
receiving, from the computing device of the customer and via an interaction with the user interface, a second request to modify a first permission of the one or more first permissions associated with the token; and
based at least in part on the second request, causing the first permission associated with the token to be modified via a component of the mobile payment application that tracks the one or more first permissions and the one or more second permissions.
10 . The system as claim 9 recites, the operations further comprising prior to receiving the first request, and based at least in part on detecting a selection of a payment field associated with the mobile payment application, causing a prompt for confirmation to process the payment for the transaction via the mobile payment application to be presented via the instance of the mobile payment application, wherein the first request is received in association with a response to the prompt.
11 . The system as claim 9 recites, wherein the token is associated with the customer and the mobile payment application.
12 . The system as claim 9 recites, wherein the user interface further enables the customer to manage a setting of at least one of the one or more other requesting applications.
13 . The system as claim 9 recites, wherein the first request is associated with a first time, the operations further comprising:
receiving, at a second time, from the third-party application, and based at least in part on the token having been sent to the third-party application, a third request to authorize the account of the customer for another payment for another transaction between the customer and the third-party merchant;
based at least in part on receiving the third request, determining whether the account of the customer is authorized for the other payment of the other transaction; and
causing another indication of whether the other payment is authorized or denied to be provided to the third-party application via the instance of the mobile payment application.
14 . The system as claim 9 recites, wherein modifying the first permission associated with the token comprises revoking use of the token by the third-party application or invalidating the token.
15 . One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
receiving, from a third-party application associated with a third-party merchant, a first request to authorize an account of a customer for payment of at least a transaction between the customer and the third-party merchant;
sending, to the third-party application and based at least in part on the first request indicating that the third-party merchant is permitted to store payment data associated with the account of the customer for processing one or more payments for one or more future transactions, a token to be stored for processing the one or more payments for the one or more future transactions, wherein invoking the token for the one or more future transactions causes a mobile payment application to execute in the background and initiates a communication session between the third-party application and the mobile payment application for automatic payment without the customer having to provide the payment data in association with the one or more future transactions;
causing a user interface to be presented via an instance of the mobile payment application, associated with a payment service, on a computing device of the customer, wherein the user interface includes interactive elements selectable to enable the customer to:
manage one or more first permissions associated with the token;
manage one or more second permissions associated with payment requests from one or more other requesting applications; and
track a plurality of transactions associated with the mobile payment application, wherein the plurality of transactions includes the one or more future transactions and one or more other transactions conducted via at least one of the one or more other requesting applications;
receiving, from the computing device of the customer and via an interaction with the user interface, a second request to modify a first permission of the one or more first permissions associated with the token; and
based at least in part on the second request, causing the first permission associated with the token to be modified via a component of the mobile payment application that tracks the one or more first permissions and the one or more second permissions.
16 . The one or more non-transitory computer-readable media as claim 15 recites, wherein the token is associated with the customer and the mobile payment application.
17 . The one or more non-transitory computer-readable media as claim 15 recites, wherein the first request is associated with a first time, the operations further comprising:
receiving, at a second time, from the third-party application, and based at least in part on the token having been sent to the third-party application, a third request to authorize the account of the customer for another payment for another transaction between the customer and the third-party merchant;
based at least in part on receiving the third request, determining whether the account of the customer is authorized for the other payment of the other transaction; and
causing another indication of whether the other payment is authorized or denied to be provided to the third-party application via the instance of the mobile payment application.
18 . The one or more non-transitory computer-readable media as claim 15 recites, wherein modifying the first permission associated with the token comprises revoking use of the token by the third-party application or invalidating the token.
19 . The method as claim 1 recites, wherein the first request is received without redirecting the customer to an application store to download and install the mobile payment application based at least in part on a determination, from a deep-link associated with a selected payment field associated with the mobile payment application, that the mobile payment application is installed on the computing device of the customer.
20 . The method as claim 1 recites, further comprising:
receiving, from an individual requesting application of the one or more other requesting applications, a third request to authorize the account of the customer for payment of a second transaction between the customer and the individual requesting application;
based at least in part on at least one second permission of the one or more second permissions and transaction data associated with the second transaction, determining a level of risk of the second transaction; and
based at least in part on the level of risk exceeding a threshold, blocking the third request.