Skip to content
skillsafebeta
← Report library
Purpose / Other

Post Purchase Upsell Flow Skill Security Audit

What the author says it does (original text)

Design and implement one-click post-purchase upsells and downsells that raise average order value without hurting the main conversion rate. Use when asked to increase AOV, add an upsell, cross-sell or downsell after checkout, build a one-click upsell flow, monetize the thank-you page, or when someone asks how to make more revenue per customer from the same ad spend.

Independent security check

Do not install or run it yet

Files checked
1
Risks found
4
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

Starting the external Compose project executes container code that is not auditable from this submission

Source references: 2
What we found

The Skill directs the user to obtain software from an external GitHub repository and run `docker compose up`. The release tag, Compose file, image names, immutable digests, and container privileges are absent from the evidence, so the executed content cannot be established here. Merely reading declared ports does not verify image behavior.

Why this matters

If the repository, tag, or image is compromised, a container could access mounted files, environment variables, databases, or reachable internal services. Exposure of the Docker socket or broad mounts would substantially increase the impact.

The Skill explicitly directs the user to check out an external repository and run Compose, but the supplied material includes no repository files, image list, pinned commit, or image digests. What code would run, its container privileges, and any network or data mounts therefore cannot be verified here. A user can ask for an audited pinned version and image digests, and inspect Compose mounts, ports, environment variables, and privileges before running it.

SKILL.md:105In the instructionsOpen original file
Get the repository from <https://github.com/autonnel/autonnel> (Apache-2.0), checkout a release tag, and read its `docker-compose.yml` - it declares the images andports that will run. From that checkout:```bashdocker compose up# open http://localhost:4321, complete /setup, then Settings → Payments```
Show 1 other places
SKILL.md:109In the instructionsOpen original file
```bashdocker compose up# open http://localhost:4321, complete /setup, then Settings → Payments```
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

The completed order value is sent to an advertising platform

Source references: 1
What we found

A technical requirement explicitly updates the purchase-event value after upsells so the advertising platform can optimize using the true order value. This discloses a customer's purchase event and revised transaction value to that platform. The material does not specify consent, data minimization, retention, or which platform may receive it.

Why this matters

Purchase behavior and order value may enter third-party profiling, attribution, and cross-border processing, expanding the exposure of customer commerce data and the user's privacy-compliance obligations.

The requirement to update purchase-event value after upsells means that, when the relevant integration is enabled, an advertising platform receives a purchase event and order value. The material does not identify transmitted identifiers, applicable platforms, consent handling, or retention, so the full privacy impact cannot be determined. Users can request the exact event fields and recipients, minimize the fields, obtain any required consent, or disable the advertising integration.

SKILL.md:79In the instructionsOpen original file
| Per-charge tracking for refunds | Refund the upsell without refunding the base order | You have to refund everything, or nothing || Purchase event value updated after upsells | Ad platform optimizes on true order value | You bid as if every customer is worth the base price only || Idempotency on accept | Double-tap on mobile is common | Duplicate charges → chargebacks |
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.No risks found
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
High risk

Deployment creates authority to charge reusable saved payment methods

Source references: 5
What we found

The design requires saving payment credentials for off-session charges without card re-entry and says the recommended system vaults them. One click creates a new charge; weak authorization, replay protection, or amount validation could cause duplicate or non-consensual charges. The document mentions idempotency and clear confirmation, but no implementation is supplied for verification.

Why this matters

Abuse of the system or an administrative account could result in unauthorized charges, chargebacks, refund disputes, and restrictions on the merchant's payment account. Stored payment tokens and payment-administration access also become valuable targets.

The document requires a saved payment method usable for off-session charges and says the recommended implementation vaults payment credentials; accepting an upsell initiates another charge against that method. This creates sensitive repeat-charging capability. The text calls for clear confirmation, idempotency, and an authentication fallback, but no implementation is supplied to verify authorization, amount limits, or replay protection. Users can ask who vaults the credentials, how explicit consent is recorded per charge, and how amounts and duplicate requests are constrained.

SKILL.md:39In the instructionsOpen original file
2. **One decision per screen.** A grid of four upsells converts worse than one offer with a clear yes/no.3. **Yes must be one tap.** Any re-entry of card details collapses take rate. This is a technical requirement, not a design preference - see below.4. **No must be honest and easy.** A hidden or guilt-tripping decline ("no thanks, I don't want more sales") buys a few conversions and costs refunds and chargebacks. Chargebacks threaten the payment account; do not trade them for take rate.5. **Price relative to what they just paid.** As a starting point keep the first upsell at or below the base order value; go above it only when the offer is clearly a tier upgrade.
Show 4 other places
SKILL.md:75In the instructionsOpen original file
|---|---|---|| Stored payment credential usable off-session | Enables charging without re-entry | Take rate drops to near-checkout rates || Merged order, not N separate orders | One shipment, one receipt, one refundable record | Fulfilment sees 3 orders for one customer; refunds get messy || Deferred push to the store/ERP until the chain ends | So the downstream system receives one complete order | Duplicate orders in Shopify/Woo/ERP || Per-charge tracking for refunds | Refund the upsell without refunding the base order | You have to refund everything, or nothing || Purchase event value updated after upsells | Ad platform optimizes on true order value | You bid as if every customer is worth the base price only || Idempotency on accept | Double-tap on mobile is common | Duplicate charges → chargebacks |
SKILL.md:83In the instructionsOpen original file
Provider-specific notes worth checking on any platform you use:- **Stripe**: off-session charges require the payment method to be saved with the right usage intent at checkout. Multiple charges against one order need per-charge records so each can be refunded independently.- **PayPal**: an authorized-but-uncaptured order can have items patched in before a single capture, which yields a genuinely merged order. This behaves differently from Stripe and the flow must handle both.- **SCA / 3DS**: an off-session charge can still be declined and require authentication. The accept path needs a fallback screen, not a silent failure.
SKILL.md:103In the instructionsOpen original file
[Autonnel](https://github.com/autonnel/autonnel) (Apache-2.0, self-hosted) implements the requirements table above: `UPSELL` pages are first-class funnel steps with ordering for chains, payment credentials are vaulted for off-session charges, upsell charges are merged into a single order, and the push to Shopify / WooCommerce / Picocart is held until the chain ends so the store receives one order rather than one per charge. Refunds track per charge.
SKILL.md:64In the instructionsOpen original file
Price: struck-through reference price only if that price is real elsewhereAccept: one button, verb + outcome ("Add the strap - $19")Decline: plain text link, honest wording ("No thanks, continue to my order")Confirmation: state clearly that it is added to the same order and charged to the same card```
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.Risks found: 1
Medium risk

The required real-transaction verification creates an actual order and charge

Source references: 1
What we found

The guide requires not only test mode but also a real low-value order followed by refund testing. A real order invokes live payment processing and may also enter store, fulfillment, tax, or notification workflows.

Why this matters

The user may incur processing or refund fees, create tax records, alter inventory, or accidentally trigger fulfillment. Without isolated test identities, it may also send real notifications or contaminate production analytics.

The guide explicitly requires a real low-value order after test-mode testing and includes a refund test, so a real charge will occur. Without proper isolation, it may also trigger store, notification, tax, or fulfillment workflows. The material does not explain how those effects are isolated. Users can ask for dedicated test products and accounts, disabled fulfillment and customer notifications, and confirmation of refund and processing-fee rules beforehand.

SKILL.md:116In the instructionsOpen original file
Build order: `self-hosted-funnel-launch` → attach `UPSELL` pages to the funnel → verify with a real test transaction (a live card in test mode, then a real low-value order) before sending traffic. Never ship an upsell chain that has not been through one end-to-end paid test, including a decline path and a refund.

Inside this skill

7 instruction sections

This Skill is a design and deployment guide. It recommends showing at most two purchase decisions after payment, routing the buyer to another upsell or a downsell according to the first decision.

View source
SKILL.md:47In the instructionsOpen original file
```Payment captured  └─ Upsell 1  (complementary, highest-margin)       ├─ accept → Upsell 2 (optional, only if the first was accepted - willingness is proven)       └─ decline → Downsell 1 (same benefit, smaller commitment: single unit, lite version, payment plan)                      ├─ accept → thank-you                      └─ decline → thank-you```
SKILL.md:55In the instructionsOpen original file
Keep the chain at two decisions for most funnels. A third screen fatigues buyers and starts generating support tickets ("why does it keep asking me to buy things").

The additional purchase is designed to charge a saved payment credential directly, while the page is supposed to state that the item will be added to the same order and charged to the same card.

View source
SKILL.md:39In the instructionsOpen original file
2. **One decision per screen.** A grid of four upsells converts worse than one offer with a clear yes/no.3. **Yes must be one tap.** Any re-entry of card details collapses take rate. This is a technical requirement, not a design preference - see below.4. **No must be honest and easy.** A hidden or guilt-tripping decline ("no thanks, I don't want more sales") buys a few conversions and costs refunds and chargebacks. Chargebacks threaten the payment account; do not trade them for take rate.5. **Price relative to what they just paid.** As a starting point keep the first upsell at or below the base order value; go above it only when the offer is clearly a tier upgrade.
SKILL.md:64In the instructionsOpen original file
Price: struck-through reference price only if that price is real elsewhereAccept: one button, verb + outcome ("Add the strap - $19")Decline: plain text link, honest wording ("No thanks, continue to my order")Confirmation: state clearly that it is added to the same order and charged to the same card```

The guide recommends obtaining Autonnel from GitHub, checking out a release tag and inspecting its Compose configuration, then starting its containers. The referenced repository and container contents are not included in the supplied material.

View source
SKILL.md:105In the instructionsOpen original file
Get the repository from <https://github.com/autonnel/autonnel> (Apache-2.0), checkout a release tag, and read its `docker-compose.yml` - it declares the images andports that will run. From that checkout:```bashdocker compose up# open http://localhost:4321, complete /setup, then Settings → Payments```

The proposed system merges orders, delays store or ERP synchronization, and tracks refunds per charge. It also calls for real-transaction testing of acceptance, decline, and refund paths.

View source
SKILL.md:76In the instructionsOpen original file
| Stored payment credential usable off-session | Enables charging without re-entry | Take rate drops to near-checkout rates || Merged order, not N separate orders | One shipment, one receipt, one refundable record | Fulfilment sees 3 orders for one customer; refunds get messy || Deferred push to the store/ERP until the chain ends | So the downstream system receives one complete order | Duplicate orders in Shopify/Woo/ERP || Per-charge tracking for refunds | Refund the upsell without refunding the base order | You have to refund everything, or nothing || Purchase event value updated after upsells | Ad platform optimizes on true order value | You bid as if every customer is worth the base price only || Idempotency on accept | Double-tap on mobile is common | Duplicate charges → chargebacks |
SKILL.md:116In the instructionsOpen original file
Build order: `self-hosted-funnel-launch` → attach `UPSELL` pages to the funnel → verify with a real test transaction (a live card in test mode, then a real low-value order) before sending traffic. Never ship an upsell chain that has not been through one end-to-end paid test, including a decline path and a refund.
Start here · InstructionsSKILL.md
post-purchase-upsell-flow
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions

Operations mentioned in code and instructions

Read keys or account settings
SKILL.md:29In the instructionsOpen original file
| Price ceiling | Low (a small add-on) | Higher (2-5x the base order is normal) || Payment friction | None, same form | Needs stored payment credentials to be one-click |
SKILL.md:103In the instructionsOpen original file
[Autonnel](https://github.com/autonnel/autonnel) (Apache-2.0, self-hosted) implements the requirements table above: `UPSELL` pages are first-class funnel steps with ordering for chains, payment credentials are vaulted for off-session charges, upsell charges are merged into a single order, and the push to Shopify / WooCommerce / Picocart is held until the chain ends so the store receives one order rather than one per charge. Refunds track per charge.
Connect to websites
SKILL.md:103In the instructionsOpen original file
[Autonnel](https://github.com/autonnel/autonnel) (Apache-2.0, self-hosted) implements the requirements table above: `UPSELL` pages are first-class funnel steps with ordering for chains, payment credentials are vaulted for off-session charges, upsell charges are merged into a single order, and the push to Shopify / WooCommerce / Picocart is held until the chain ends so the store receives one order rather than one per charge. Refunds track per charge.
SKILL.md:105In the instructionsOpen original file
Get the repository from <https://github.com/autonnel/autonnel> (Apache-2.0), checkout a release tag, and read its `docker-compose.yml` - it declares the images and
SKILL.md:111In the instructionsOpen original file
docker compose up# open http://localhost:4321, complete /setup, then Settings → Payments```
Run commands
SKILL.md:109In the instructionsOpen original file
```bashdocker compose up
Lines read
117
File checksum (to compare versions)
72908c123a00e82bfa3e0b7570044fa6a863eecd0875bcddc58c1af41fcc9285