Introduction

Recurring access provides notifications when new or changed data is available for your end-users' payroll account and removes authentication friction for returning end-users. You can use this information to determine changes in existing direct deposit allocations, employment status, or income, as well as to get an ongoing stream of shifts and paystubs data for connected accounts. We're excited to be the first provider to capture dynamic changes in payroll data.

Use Cases

• Direct Deposit Allocations Monitoring: Direct Deposit Allocations (DDA) Monitoring alerts you to changes in a user's direct deposit allocations, such as increases and decreases in allocation amounts, the removal of an existing allocation, or the addition of a new allocation. We'll pull direct deposit allocations data from this connection daily and proactively notify you of any changes.
• Income and Employment Monitoring: Income, Employment, Identity, Paystubs, and Shifts (I&E) Monitoring alerts you to changes in a user's information, such as if their employment status has changed or if a new paystub is available. We'll pull income and employment data from this connection daily and proactively notify you of any changes.
• Anti-fraud Direct Deposit Switching: Utilize our identity endpoint to match the identity of the end-user with the name and other info with the target account on file prior to processing a direct deposit switch.
• Direct Deposit Updates: Allow end-users to update their direct deposit allocation amount seamlessly without having to re-enter their credentials.

How Does It Work?

Recurring access has two primary components that allows Pinwheel to maintain on-going connectivity to an end-user's payroll accounts.

• Monitoring: For platforms and employers where we are able to maintain a persistent connection, data is automatically refreshed daily. You will be notified via a webhook event whenever there is new or changed data for a given payroll account.
• On Demand Updates
  : For returning users, Pinwheel Link can authenticate an end-user without asking them to re-enter credentials. This removes friction for end-users making updates to their allocations or providing you with new or updated data. Note: if the user has multi-factor authentication enabled on their account, user action may be required to complete the login step.

Some payroll platforms and employers don't support persistent connections so it's essential that you incorporate both Monitoring and On Demand Updates into your implementation if you want to maintain on-going access to your end-user's payroll data.

Billing

Monitoring and On Demand Updates are treated as a single billed product. If Recurring Access is enabled for your workspace you will be billed monthly for a connected account which enables proactive monitoring where available and allows you to complete unlimited On Demand Updates.

FAQ

How can I see when data was last refreshed? Last updated?

By refreshed we mean data has been checked for changes.

By updated we mean data has been changed.

If you have Monitoring turned on, we'll send you webhook events whenever data was updated. If you use On Demand Updates, we'll send you webhook events whenever data is refreshed, even if no update was detected.

The GET /accounts and GET /accounts/{id} endpoints include data_refreshed_at and data_updated_at objects in their responses. The objects have an entry for each job type with the ISO 8601 timestamp of when the data was last refreshed or updated.

The GET /accounts/{id}/employment, GET /accounts/{id}/identity, and GET /accounts/{id}/income provide data.created_at, data.updated_at, and meta.refreshed_at. GET /accounts/{id}/paystubs and GET /accounts/{id}/shifts provide data[].created_at and meta.refreshed_at, but not updated_at since shifts and paystubs records are immutable.

Can shifts and paystubs records be updated?

No, individual records are immutable. We'll represent changes to a user's shifts or paystubs as old record deletions and new record additions. We'll communicate which records have been deleted and which have been added via the deleted and added properties on the shifts.added and paystubs.added webhook events.

Often, we will report that shift records changed because shifts were revised by the employer. Sometimes, we may delete/add shift or paystubs records because new field-level data is available for them and we want to ensure you have all useful information. To optimize latency, we look for changes in the past 30 days of records.

Please contact [email protected] for access to our Developer Dashboard.