Skip to content
Kiragu MainaSystems workspace
Systems onlineSend a brief
All tools

Payment Recovery Workbench

Trace one payment through its saved intent, verification, and business effects before deciding what is safe to retry.

Developers connecting payments to subscriptions, downloads, or service activation.

Visual examples. Plain language. Go at your own pace.

Payment Recovery Workbench

Package preview. Illustrations use sample data.

Follow the payment evidenceExample
One order. Two payment notices.

No service activation recorded

Read the evidence before retrying.

The challengePayment confirmed; service missing
Illustration only. These are sample screens and values.

Slide 1 / 6

The payment succeeded. The service did not

A customer has a payment reference but their download or subscription is missing. Several systems have part of the story.

  • A successful browser return is not payment verification.
  • Blind retries can repeat a charge or grant service twice.
1 of 6

What this means for your project

Help your AI investigate why payment and service records disagree before attempting a repair.

The money arrived. The customer is still waiting.

A customer paid for access, but the account still looks unpaid. Follow one reference through the saved order, verification evidence, and service activation. Find the missing step before deciding whether a retry is safe.

How would I use this with AI?

A skill is a set of instructions and examples for your AI coding assistant. You bring your idea and your project. The skill gives the assistant a process to follow.

  1. Tell your AI what you want to do and share the complete package.
  2. Work through the setup together. You may need accounts or tools listed below.
  3. Review and test the result before using it in your project.

You receive instructions and working examples to use with your own tools. Setup and review remain part of the work.

Try this as your first task
You bring
Sanitized records for one payment reference, including intent, verification, and service or download effects.
Work toward
An offline findings report and a bounded recovery plan to rehearse.

Check the result: The report distinguishes evidence from assumptions, and no retry can blindly repeat money movement or service.

Use this after installing the package. Your AI tool and any external services are separate.

Not sure where to start? Ask about a project like yours.

Try a small example

Made-up example
  1. Read intent
  2. Check verification
  3. Count business effects
  4. Plan recovery

Starting point

Two notices arrived, but service is still missing

What changes

Separate a repeated notice from a repeated business effect

Change the number of service activations for one imaginary order. No payment or recovery action is performed.

Invented teaching fixture. No files are uploaded, no payment is made, and no external app is contacted.

See how it works

Step 1 of 6

The payment succeeded. The service did not

A customer has a payment reference but their download or subscription is missing. Several systems have part of the story.

Starting situationA customer paid but the service is not active
Where it breaksA blind retry can repeat money movement or service
Made-up example. Try the interactive preview to see what changes.
  • A successful browser return is not payment verification.
  • Blind retries can repeat a charge or grant service twice.

Step 2 of 6

Build a trace you can act on

Follow one reference from the saved intent through provider evidence to the committed business effect and delivery.

BeforeIntent, verification, and delivery records disagree
AfterA scoped trace shows missing or duplicate effects
Made-up example. Try the interactive preview to see what changes.
  • Separate a missing effect from a repeated effect.
  • Record what is unknown before choosing a recovery.

Step 3 of 6

Read evidence before changing state

Map sanitized observations to the input contract, run the offline audit, and use the findings to prepare a bounded repair plan.

  1. Read the saved intent
  2. Compare verification evidence
  3. Inspect committed effects
  4. Rehearse a bounded recovery
Steps shown in the example.
  • Check amount, currency, customer, tenant, and provider mode.
  • The tool reads your supplied evidence; it does not call the provider or change the system.

Step 4 of 6

Compare a retry with a duplicate effect

Two payment notices are not automatically two deliveries. Change the sample effect count and see which case needs investigation.

What to tryCompare zero, one, and two activations for one order
Expected resultDistinguish missing service from duplicate service
Made-up example. Try the interactive preview to see what changes.
  • The public preview is illustrative and makes no provider requests.
  • Run the shipped tool against the richer sample trace to inspect real audit output.
Try the example

Step 5 of 6

A workbench for the awkward cases

Use the trace contract and recovery matrix to investigate delayed notifications, unknown initialization, mismatched evidence, and access revocation.

SKILL.md
Investigation and recovery workflow
scripts/audit.mjs
Offline checks on normalized observations
examples/trace.json
Synthetic trace you can run before adapting your own
docs/
Input contract and recovery guidance
tests/
Eight normal and adverse cases
What the package contains. Check the release details for the exact file list.
  • A portable offline command and eight behavioral tests.
  • Guidance for background jobs, retries, and tenant boundaries.

Step 6 of 6

For the developer responsible for recovery

You need access to trustworthy evidence and a safe place to rehearse changes. A clean audit means the declared checks passed on those inputs.

What you need
  • Node.js 20 or later and a coding assistant
  • Sanitized intent, verification, and business-effect records for the scoped problem
  • A developer who can map the records to the documented contract and review findings
  • An isolated test environment before applying any recovery to your service
Limits to knowThe offline audit checks supplied evidence; it does not verify money or apply repairs
Check what you need and what the product can do before choosing it.
  • It cannot prove that supplied records are complete or truthful.
  • It never charges, refunds, or repairs the database for you.

What you receive

  • A method for tracing provider notifications, retries, background jobs, and customer access
  • An offline audit tool for normalized payment evidence
  • Checks for mismatched amounts or currencies, repeated effects, wrong tenants, and unsafe retries
  • Input contracts, recovery guidance, synthetic traces, and eight behavioral tests
See the files in the package
SKILL.md
Investigation and recovery workflow
scripts/audit.mjs
Offline checks on normalized observations
examples/trace.json
Synthetic trace you can run before adapting your own
docs/
Input contract and recovery guidance
tests/
Eight normal and adverse cases

What you need to get started

  • Node.js 20 or later and a coding assistant
  • Sanitized intent, verification, and business-effect records for the scoped problem
  • A developer who can map the records to the documented contract and review findings
  • An isolated test environment before applying any recovery to your service

What you can check here

Package version 1.0.0 / page version 1

  • Checks performed on the package

    Eight behavioral tests passed on Node 24.20.0, macOS arm64, including duplicate effects, mismatches, tenant boundaries, unsafe retries, and equivalent evidence with different JSON property order. These are offline synthetic checks, not live provider certification.

Will it work with your tools?

Node 24.20.0 / macOS arm64Tested
Core checks ran after extracting the release archive into a fresh directory. Node 20 or later is required; other runtime versions and external integrations need checking in your setup.

Before you choose

Read the paid skill terms for permitted use, what your purchase includes, help, and refunds.

  • One purchase covers unlimited own and client projects for one purchaser. You may modify the package and use it with your coding AI. Do not resell or publicly redistribute the standalone package. Later versions may be sold separately. See the paid skill terms for help and refunds.
  • You supply accurate, sanitized records and map them to the documented input format. An input marked verified is not independent proof from a provider.
  • The tool does not charge, refund, repair a database, or guarantee that every integration defect is found. Test a proposed recovery before applying it.
Does this replace the Paystack shop skill?

No. The shop skill helps build payment-to-download delivery. This workbench investigates disagreements in an existing integration, including services other than downloads.

Does a passing report prove that money arrived?

No. The report checks supplied evidence. Independent provider verification remains part of your integration and investigation.