Abstract: A payment service system receives a transaction instrument identifier of a transaction instrument, and associates the transaction instrument with an account associated with a first user. The system identifies rules that identify whether to request authorization from a second user to process respective transactions that involve the transaction instrument and that are associated with one of a set of transaction types. The system receives a transaction indication indicating a request to use the transaction instrument for a transaction. The system determines, based on information about the transaction and the one or more rules, that the transaction is categorized into a first transaction type. The rules indicate that the authorization from the second user is to be requested for the first transaction type. The system receives an authorization to process the transaction from a user device associated with the second user, and automatically facilitates processing of the transaction.

Abstract: In one embodiment, techniques include a method of handling transactions for a pack of security assets. The method includes identifying a subset of a set of security assets for inclusion in the pack of security assets to be recommended to a user based on an analysis of one or more criteria associated with the user. The method includes causing an electronic device to display a user interface to facilitate a purchase of the pack. The method includes, in response to determining a user selection corresponding to a request to purchase the pack and a specified value of currency: calculating a number of base units of each security asset based on the existing value of a base unit of each security asset, including a fractional portion of the base unit; and assigning, for each security asset, ownership of the calculated number of base units of each security asset to the user.

Abstract: Particular embodiments provide, by a payment service system, a payment application to a first user device associated with a primary user and a second user device associated with a secondary user. The payment service system is configured to process financial transactions for users utilizing respective accounts based on interactions within the payment application. The payment service system establishes a secondary account for the secondary user. The payment service system receives a request for a payment instrument to be associated with the secondary account. The payment service system receives an identifier associated with the primary user. The payment service system uses the identifier to send a message that includes a mechanism that when actuated enables the primary user to configure a primary user account for the primary user via the payment application. The payment service system controls access to the payment instrument via the secondary account with a set of features.

Abstract: In one embodiment, techniques include a method of handling transactions for a pack of security assets. The method includes identifying a subset of a set of security assets for inclusion in the pack of security assets to be recommended to a user based on an analysis of one or more criteria associated with the user. The method includes causing an electronic device to display a user interface to facilitate a purchase of the pack. The method includes, in response to determining a user selection corresponding to a request to purchase the pack and a specified value of currency: calculating a number of base units of each security asset based on the existing value of a base unit of each security asset, including a fractional portion of the base unit; and assigning, for each security asset, ownership of the calculated number of base units of each security asset to the user.

Abstract: Particular embodiments receive, by a payment service and via a first user device associated with a first user, a request to create an account with a payment service associated with the payment service. The payment service dynamically selects, based on user data associated with the first user, a primary onboarding flow or a secondary onboarding flow for creating a new account for the first user. Based on a determination by the payment service that the first user is not authorized for a new primary account via the primary onboarding flow, the payment service initializes the secondary onboarding flow to create a new secondary account for the first user. The new secondary account is associated with a different set of payment functionalities than primary accounts and the new secondary account requires authorization from a primary account associated with a second user.

Abstract: Particular embodiments receive, by at least one computing device of a payment service, a request to configure a goal to associate with a user account of a user, where the goal is associated with a condition that, when satisfied, causes an incentive to be associated with the user account. The at least one computing device generates a data object for tracking completion of the goal, where the data object is stored in a datastore by the payment service. The at least one computing device monitors, in near-real-time, at least one of managed transaction data associated with users of the payment service or interaction data associated with the user. The at least one computing device determines, based at least in part on comparing at least one of the transaction data or the interaction data to at least the condition, satisfaction of the condition.

Abstract: A payment service system receives a transaction instrument identifier of a transaction instrument, and associates the transaction instrument with an account associated with a first user. The system identifies rules that identify whether to request authorization from a second user to process respective transactions that involve the transaction instrument and that are associated with one of a set of transaction types. The system receives a transaction indication indicating a request to use the transaction instrument for a transaction. The system determines, based on information about the transaction and the one or more rules, that the transaction is categorized into a first transaction type. The rules indicate that the authorization from the second user is to be requested for the first transaction type. The system receives an authorization to process the transaction from a user device associated with the second user, and automatically facilitates processing of the transaction.

Abstract: In one embodiment, a method includes associating, by a payment service and in a datastore maintained by the payment service, interactions with a matrix barcode with an action by the payment service involving a first account associated with a first user of the payment service. The matrix barcode corresponds to a claimable token stored in the datastore. The method includes receiving, by the payment service and from a computing device of a second user of the payment service, an indication that the computing device has interacted with the matrix barcode corresponding to the claimable token. The method includes identifying, by the payment service via the datastore, the claimable token associated with the matrix barcode. The method includes initiating, by the payment service and based on the claimable token, the associated action involving the first account.

Abstract: A payment service generates multiple user profiles, each profile associated with a different user. Each user profile may be linked to multiple transaction cards and multiple numerical balances. Multiple transaction cards can be linked to a same numerical balance—even if the cards are from different user profiles. Restrictions, such as transaction type blacklists and whitelists or parent/guardian permission relationships, can be placed on particular numerical balances, or on access to particular numerical balances by particular cards. Numerical balances and transactions using particular cards may be tracked using user profiles with access to those cards and numerical balances.

Abstract: In one embodiment, a method includes identifying, by a payment service, a plurality of security assets for inclusion in a pack of security assets. A value of the pack of security assets may be determined based on weighted values of a base unit of each of the security assets. Information may be sent to a first user's client device to display a user interface to purchase the pack of security assets. In response to receiving a purchase request in a specified amount, the payment service may calculate, for each of the security assets in the pack, the base units of the security asset based on the respective assigned weight and the value of a base unit of the security asset. Finally, for each of the security assets in the pack, ownership of the calculated number of base units of the security asset may be assigned to the first user.

Abstract: In one embodiment, a method includes receiving, from a computing device of a first user, a request to transfer funds from a first account associated with the first user to a second account associated with a second user. The request to transfer funds may be generated by receiving a first token at the computing device of the first user through near-field communication with a first payment card and determining that the first token is associated with the second user. The method includes sending, in response to receiving the request to transfer funds, to the computing device of the first user, a request to authorize the transfer to the second account associated with the second user. The method includes receiving, from the device of the first user, an indication of authorization, wherein the indication of authorization is generated by receiving a second token at the device of the first user.

Abstract: A transaction card associated with a payment service may be purchased by a customer without the customer having a user profile with the payment service. The user scans a card identifier from the transaction card or from the transaction card's packaging using a mobile device, which then sends the card identifier to the payment service. The payment service may use the card identifier to generate a user profile that the payment service can automatically link to the transaction card. The user can track transactions made using the transaction card via the user profile.

Abstract: A payment service generates multiple user profiles, each profile associated with a different user. Each user profile may be linked to multiple transaction cards and multiple numerical balances. Multiple transaction cards can be linked to a same numerical balance—even if the cards are from different user profiles. Restrictions, such as transaction type blacklists and whitelists or parent/guardian permission relationships, can be placed on particular numerical balances, or on access to particular numerical balances by particular cards. Numerical balances and transactions using particular cards may be tracked using user profiles with access to those cards and numerical balances.

Abstract: A transaction card associated with a payment service may be purchased by a customer without the customer having a user profile with the payment service. The user scans a card identifier from the transaction card or from the transaction card's packaging using a mobile device, which then sends the card identifier to the payment service. The payment service may use the card identifier to generate a user profile that the payment service can automatically link to the transaction card. The user can track transactions made using the transaction card via the user profile.