Stripe, Inc.

Microsoft Technology Licensing, LLC

Ji Huang

Dharma Kiritkumar Shukla

Karthik Raman

Momin Mahmoud Al-Ghosien

Shireesh Kumar Thota

Pankaj Sharma

Alexander Thiemann

Sujit Vattathil Kuruvilla

Madhan Gajendran

Atul Katiyar

Ankur Savailal Shah

Tushar Dhoot

Stefan Krzysztof Gawrys

Shreshth Singhal

Tanin Na Nakorn

Ovidiu Constantin Platon

Bhalakumaaran Erode Ranganathan

Mikhail Mikhailovich Koltachev

Adam Eagle

Digvijaysinh Govindbhai Makwana

Subramanyam Pattipaka

Arsalan Ahmad

Peter Wang

Xu Rui

Atikh Bana

Hongshan Zhou

Hari Sudan Sundar

Hemant Kumar

Liang Li

Rajeev Sudhakar Bhopi

Kiran Kumar Kolli

Padma Priya Aradhyula Bhavani

Junyan Guo

Arne Roomann-Kurrik

Alisa (Shuhui) He

Venkata Sivaramakrishna Ramadugu

Yu-Ting Tsai

Mohammad Derakhshani

Denis Rystsov

Swarnim Vyas

Systems, methods and apparatuses for implementing user customizable policies for revenue recognition are described. In some embodiments, user inputs are received from a merchant that specify components of a set of revenue recognition rules to apply to transactions of the merchant on a per transaction basis, wherein each revenue recognition rule specifies a set of conditions to be met to trigger its application, a rule identifier, status, and whether the revenue recognition rule is applied at least one of: a specified product; a specified invoice; a specified customer; a specified payment; a specified refund; and a specified dispute. The user inputs are converted into rules to enable the rules to be matched to the transactions. A transaction is tracked by a server computer system. One or more applicable revenue recognition rules are identified to apply to the transaction, and revenue recognition is performed against the transaction.

Systems, methods, and apparatuses for implementing user customizable policies for revenue recognition

The present disclosure is directed to systems and methods that provide support for customized versions of functions that operate on a resource of a commerce platform by giving customers the ability to write custom versions of such functions that employ more advanced/complex logic that what is offered by default configurations for the functions. A custom scripting language may be added to the API of the commerce platform, which may allow customers to define scripts that specify the desired custom functionality. In response to receiving a request to customize the function from a customer, a function signature specifying information about the custom version of the function may be provided to the customer. Upon receiving a script defining a custom version of the function, the script may be stored on the resource object representing the resource the custom function is to operate on.

Extensible custom configurability for stateful API resources

Aspects of the subject technology include receiving from a user device a request for obtaining data associated with the user device. The request is addressed to a destination device. Aspects also include determining with a first controller whether to transmit the request to the destination device via a first path. The determination is based on a first success rate of the first path. Aspects also include transmitting the request to the destination device via the first path in response to a determination to transmit the request to the destination device via the first path. Aspects also include determining, with a second controller, whether to transmit the request to the destination device via a second path, in response to a determination not to transmit the request via the first path. The determination is based on a second success rate of the second path.

Adaptive control loop routing via cascading controllers

The disclosure generally describes one or more techniques for authenticating a webhook endpoint with a webhook server. Some techniques include a webhook server sending a seed with a webhook endpoint after the webhook endpoint is registered with the webhook server. In some examples, the webhook server generates the seed to send to the webhook endpoint and stores the seed with a key associated with the webhook endpoint. In such examples, the webhook server does not send data associated with the particular events to the webhook endpoint until the webhook endpoint acknowledges receipt of the seed while the seed is still valid.

Reverse webhook authentication

A method for preventing race conditions in a database comprises: setting a first numerical entry and a second numerical entry in a database; receiving a first online transaction; responsive to determining a lock of the database is in progress due to a second received online transaction, suspending the first online transaction; removing the lock after the second received online transaction is completed; responsive to determining that the first entry is greater than zero, decrementing the first entry by an amount indicated in the first online transaction; responsive to determining the second entry is greater than zero, decrementing the second entry; processing the first transaction; and generating an online transaction record for the first transaction and storing the generated record in an online transaction database.

Database locking mechanism

A method comprises: setting an first entry and an second entry in a database; receiving a first online transaction; responsive to determining a lock of the database is in progress, suspending the first online transaction; updating the first entry; removing the lock; receiving a second online transaction; responsive to determining that the first field is greater than zero, decrementing the first field by an amount indicated in the second online transaction; and responsive to determining the second entry is greater than zero, decrementing the second entry.

Database race condition prevention

In an example embodiment, a solution is provided that aggregates records as they are submitted to a third party (on the write path) rather than performing a real-time aggregation when a request is processed that needs the aggregation (read path). More particularly, in an example embodiment, a caching layer is introduced that avoids having to read all usage events to compute an aggregation when a request is received for aggregated data. The caching layer maintains values for various metrics that require aggregation.

Usage record aggregation

A method and apparatus for a first service processing system receiving and responding to a service request using a time context of a service time protocol is described. The method may include receiving a network based message associated with a service. The method may also include determining whether a service time context has been passed to the first service processing system from a second service processing system in the request. Furthermore, the method can include when no service time context is determined to have been passed to the first service processing system in the request, generating a current service time from a combination of a current physical time of the first service processing system and an initial counter time, performing a task associated with the service, and transmitting a second network based message that comprises the current service time as time context metadata associated with the performance of the task to a second service processing system.

Systems and methods for context-aware event ordering protocol for distributed service systems

A method and apparatus for performing cross-platform contract validation are described. In one embodiment, the method for validating compatibility between first and second endpoints, the method comprising: accessing a memory storing a machine-readable contract specifying a request-response pair in a file, the request-response pair consisting of an expected request that the second endpoint expects to receive from the first endpoint and an expected response that should be provided by the second endpoint according to the expected request from the first endpoint; and performing multi-platform contract validation by performing independent tests for the first and second endpoints, using the expected request and expected response specified in the machine-readable contract.

Cross-platform contract validation

Systems, methods and apparatuses for implementing user customizable policies for revenue recognition are described. In some embodiments, a method comprises: tracking, by a network commerce system, a plurality of transactions; determining one or more revenue recognition rules of a plurality of revenue recognition rules that applies to each transaction of the plurality of transactions based on results of matching performed between conditions of each of the plurality of revenue recognition rules and one or more characteristics of said each transaction, the conditions of each rule including an effective time period during which individual transactions are subject to the rule; and automatically performing revenue recognition for each transaction according to one of the one or more revenue recognition rules determined to apply to said each transaction using based on results of matching conditions of one revenue recognition rule and the one or more characteristics of said each transaction.

A clock data structure is introduced. An instance of the clock data structure can be attached to a billing data structure, such as a billing data structure that corresponds to a recurring payment. The instance of the clock data structure has a value that represents a frozen time&#x2014;i.e., a specific time that does not change unless instructed to. The billing data structures to which the clock data structure is attached operate as if the real time is the frozen time on the clock. Since the time is frozen, users wishing to test the billing data structure can update their system configurations at specific times, and subsequently advance the time in the clock data structure instance to see the effects on those configurations, as well as on other parts of the system, including asynchronous messaging and processing, and processes that involve other entities.

Deterministic validation of billing integrations through simulated time

A method and apparatus for deleting resources are described. In one embodiment, the method comprises: detecting, by a network commerce system, a deletion request in a first message sent over a network as an electronic communication to delete a first resource; identifying one or more additional resources that have a hierarchical relationship to the first resource, including identifying one or more child resources related the first resource, the one or more child resources being in a parent-child relationship with the first resource as the parent; causing a module of the network commerce system to perform a delete action with respect to the first resource, where the delete action deletes the first resource and causes the one or more child resources to be deleted in the future and to appear deleted when receiving access requests prior to deletion of the one or more child resources; detecting, by the network commerce system, an access request in a second message sent over the network as an electronic communication to access one child resource of the one or more child resources after deletion of the first resource but prior to deletion of the one child resource; determining, in response to the access request, if the first resource has been deleted; and denying access to the one child resource if the first resource is determined to have been deleted.

Constant-time cascading deletion of resources

A server set for a data set may designate a subset of 'master' servers that update the data set in order to reduce data version conflicts involving mutually exclusive updates of the data set. Multi-master configurations may fulfill the performance constraints, and the subset of masters may detect and resolve data version conflicts. However, if multiple masters perform conflict resolution for a particular data version conflict, the resolution may produce inefficiency and redundancy (if the masters reach the same outcome) or additional data version conflicts (if the masters reach different outcomes). Instead, among the masters, a merge master may be identified that applies conflict resolution techniques to data version conflicts and forwards the conflict resolution outcome to the other masters for application to the data set to resolve the data version conflict. The other masters may temporarily store updates in a tentative update set until data version conflicts are resolved.

Merging conflict resolution for multi-master distributed databases

Data services for workloads are often provided with a service level agreement specifying various performance guarantees (e.g., latency, availability, scalability, and consistency). Single-master architectures, in which updates to the data set are constrained to a single server, may limit the fulfillment of some performance guarantees. Presented herein are multi-master architectures, in which the server set is partitioned into at least two masters are permitted to update the data set and at least one non-master that is not permitted to update the data set. Non-masters that receive a request to update the data set forward the request to a master server for application to the data set. A master that receives the request applies it to the data set and propagates the update to other master and non-master servers. Conflicting updates may be resolved through a variety of conflict resolution techniques, optionally designating one master server as a conflict resolution server.

Growing community of inventors

Bothell, WA, United States of America

Ji Huang