Grant and revoke store access when developers join or leave

Define the grant and its end before inviting the developer

Write the actual work that needs access and the person performing it. For each system, identify the merchant-controlled owner who can grant and later remove access. Separate the developer’s interactive login from credentials used by installed integrations. Give each one its own entry, purpose, and planned end condition. A continuing store connection and a person’s temporary project access may need different treatment.

Record what the task requires before selecting a role. WordPress’s default single-site Administrator can manage plugins, themes, settings, and users. An Editor’s default content capabilities do not include those administration capabilities. Content editing and installing a payment extension are therefore different requests. Confirm the actual capabilities on the site, including custom roles and whether network administration is involved, rather than assuming a familiar role label describes every installation.

Keep a merchant-controlled administrator and authorized owner access available throughout the engagement. If that ownership is unresolved, record the blocked system and use the service’s legitimate recovery or delegation route. Do not solve a missing merchant login by making the contractor’s personal account the permanent point of control.

Grant named access and document separate machine credentials

For WordPress, the authorized administrator assigns the named person the role needed for the agreed work and records the grant. For Stripe, the authorized account owner invites the team member by email, selects the lowest permissions needed, and verifies acceptance. Stripe documents that invites expire after ten days and roles can be edited after acceptance. An invitation that was sent but not accepted is a different state from an active team member; retain that distinction in the log.

WooCommerce REST keys are created under WooCommerce > Settings > Advanced > REST API for a selected WordPress user. Read, Write, and Read/Write are distinct permissions. Record the key’s description or non-secret identifier, its associated user, its scope, and the integration or task that needs it. The consumer secret is shown once; the register should identify approved secure storage, not contain the secret.

A payment-provider team seat and a provider API credential are separate access paths. Stripe’s publishable key is intended for front-end use; secret and restricted keys are not safe to expose. Do not pass secret or restricted keys through email, chat, or a public inquiry. Use the merchant’s authorized secure credential process when a credential is actually required, and keep the decision about its scope with the authorized owner.

For hosting and domain services, use their supported individual or collaborator access and document the account or property covered. Their roles are not WordPress roles. Record separate hosting tokens, deployment credentials, or shared credentials if they exist, using names or identifiers only. Granting a website login does not settle these other access questions.

Remove the person and handle every credential they could use

At the end of the engagement, compare the planned register with the current user, team, collaborator, and credential inventories. Include permissions added during the project and pending invitations. The authorized owner removes or disables the departing person’s access through each service’s supported administration controls and records the actual completion time. A promise that the developer will stop using the account is not removal evidence.

Before removing a WordPress user, have the site administrator determine how its content and ongoing integrations will be retained under legitimate merchant control. WooCommerce links each REST key to a WordPress user and provides a Revoke action. Review and explicitly resolve each relevant key rather than assuming the effect of a user change. Revoke credentials whose only purpose was the completed engagement.

For a credential still used by the live store, identify the actual dependency and have its authorized owner arrange a supported replacement, update the dependent connection, verify the intended operation, and revoke the obsolete credential. Record the replacement by a non-secret identifier. Revocation without accounting for a continuing integration can interrupt the store, while leaving the old credential active leaves the access question open.

If a shared credential was available to the departing developer, removing their team seat does not address that copied value. The owner must resolve it separately through the service’s supported rotation or revocation process. Include relevant sessions, application credentials, and recovery access where the service provides those controls. Do not assume one password change has a universal effect across these paths.

Close the log only when the inventory and evidence agree

For each entry, record the removal or revocation result from the system that owns it, the person who performed the action, and the verification time. Check that pending invitations are resolved and that the active membership or credential list no longer grants the departed person the recorded access. Where the service exposes session controls or activity records, use them to review the affected access. Stripe documents team-member activity logging, which can support the timeline; an absence of recent activity alone is not proof of revocation.

Verify that the merchant still has the administration access required to operate the store and that any continuing integration moved to the intended authorized credential. Verification should use authorized owner access and appropriate existing operational records, not impersonation of the departed developer or a new payment made solely to check the handoff. A key that was scheduled for revocation but remains active is an open item.

Complete removal means the known access paths for the engagement have each been resolved and evidenced. It does not prove that no undisclosed credential ever existed or that a former user no longer holds an earlier downloaded file. Record any unresolved path with its owner and next action rather than certifying an inventory you cannot substantiate.

A Prism checkout-review consultation can begin with the systems involved and the access dependency affecting checkout, without credentials or customer records. Confirm the requested assistance, account authority, responsibilities, fees, and terms before work. A consultation does not itself grant access or authorize changes to a payment account.

Access grant and removal log

Keep this as an internal register for the real engagement. Repeat the relevant row in your own register for each person, account, or credential. In the final column record a non-secret identifier, task, authorized owner, permission, actual grant date, planned end, actual revocation date, and verification evidence. Leave unfinished actions open; never enter credential values.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.