Skip to content

Case study · Digital products and memberships

Closing the gap between a successful payment and a provisioned customer

Customers were paying and receiving nothing because most payment links carried no product metadata. We audited every link, rebuilt provisioning around the payment webhook and added a safety net for anything unrecognized.

85
Live payment links audited
82
Carried no product metadata
2
Paid customers found unprovisioned
0
Payments that can now land unseen

Context

A business sold memberships, a course, community access and client services through payment links created over many months. A webhook was meant to grant access on payment: a portal seat, an access code by text, a community role.

The problem

  • The webhook decided what was bought from a metadata field. A link without it recorded the money and provisioned nothing.
  • It had happened at least twice, and both cases were found by accident weeks later.
  • Tagging every link was wrong too: client invoices are not course products, and tagging them would enroll a paying client into a course.

Architecture

  1. 01Audit before fixingEvery live link was listed and classified: product sale, client invoice or retired. Only real product links received metadata; the rest were left alone on purpose.
  2. 02Metadata drives entitlementsA product link names its program. The webhook maps program to entitlements and grants all of them in one pass.
  3. 03Nothing unrecognized disappearsA payment the webhook cannot map lands in the CRM tagged for review, and the owner is alerted, so a person sees it the same day instead of weeks later.
  4. 04Retire the clutterDuplicate and stale links were deactivated, so there are fewer ways to pay for the wrong thing.

Security model

  • Webhook signatures verified before any entitlement is granted.
  • Access codes are single-purpose and issued server side only.
  • No card data touches the application.

Tasks now automated

  • Issuing the portal seat on payment
  • Texting the access code
  • Granting the community role
  • Routing unrecognized payments to a person with an alert

Time returned

~10 min
Manual provisioning removed per sale

Check the payment, create the seat, send the code, assign the role, by hand.

Weeks to same day
Time to catch an unmapped payment

Both earlier misses surfaced weeks later; now an alert fires on arrival.

85 audited
Links reviewed and classified

Every active link listed and tagged, left alone or retired.

Time figures are estimates per unit of work, based on the manual steps the build removed. Every other number on this page is measured.

Outcome

Every product sale provisions automatically; every other payment is routed to a person.

Both missed customers were identified from the audit, and the failure mode that caused them is closed.

Look for the money that arrives without a matching action. It is usually the most expensive silent failure in the stack.

Next step

Tell us which system is slowing you down.

A 15 to 20 minute scoping call. If it is a fit, scope, price and timeline follow in writing.