[tracking202]

Backlog: 1YEB ("PayKickstart IPN URL points to a file that does not exist")

This changes what was decided: read this first

The decision was "Build a PayKickstart IPN handler with signature check", and the panel it fixes promised PayKickstart's Affiliate IPN. That cannot be built as the panel describes. PayKickstart's Affiliate IPN is unsigned JSON (amount, buyer names, PayKickstart's own tracking_id, the affiliate's commission). It has no signature, no event type and no transaction id. PayKickstart allows no custom variables in it, and the affiliate's ?tid= value shows only in the affiliate's own PayKickstart account. So nothing in it names a Prosper202 click, and nothing in it can be verified.

What this PR builds instead is the vendor (product) IPN. That is the reading of the decision that has a signature to check:

• For a vendor selling through PayKickstart, the steps are: add subid=[[subid]] to the PayKickstart checkout link that is the campaign's offer URL, paste tracking202/static/paykickstart.php into each product's IPN Integration tab, and store each PayKickstart campaign's IPN secret key in Prosper202. Each campaign has its own key. PayKickstart sends the checkout link's query variables back as custom_<name>, so custom_subid is the click.
• For an affiliate, the panel now says plainly that the Affiliate IPN cannot update conversions. If the URL is still set as an Affiliate IPN, it answers 415 and says why.

Until now the URL was a 404 for everyone: the file never existed. jvzoo.php, zpn.php and slack.php are the same kind of dead URL. They are separate 1.9.79 items, and they are listed as known dead in the new check.

What changed

• tracking202/static/paykickstart.php (POST only, bootstrapped like cb202.php) runs Prosper202\PaymentNotification\Receiver with the PayKickstart adapter.

  • Verification. The request's hash is checked against every account's stored keys with PayKickstart's published HMAC-SHA1 algorithm (hash_equals), before any field is read. The account is the one whose key verifies, never one the request names (CLAUDE.md [Maintenance] Remove deprecated PHP features #16).
  • The click. It must belong to that account. Another account's click answers the same 404 as a click that does not exist ([Update] Fix CPC warnings and input length #27).
  • sales records a conversion (pixel type 2, new ledger source paykickstart) under transaction_id, at amount. The amount must be an exact decimal that fits decimal(11,5). Rebills are recorded too, each under its own transaction id.
  • refund reverses the sale its transaction_id names, through the writer's reversal path.
  • Recorded nothing (200): mode=test, subscription-payment (sales already fires for every payment), every other event, and a sale whose checkout carried no subid (no_click).
  • Dated when it happened. A sale or refund is dated by its transaction_time (decision 6).
  • Retries. A retry of a transaction already on file is 200 duplicate only when it states the same amount. Stating another amount is 409, never answered as the first ([Fix] Return 404 status #15).
  • Refusals answer statuses PayKickstart's log shows, with the reason: 400 (a field named), 403, 404, 409, 415, 500, and 503 while the database's upgrade has not run (as 1.9.79: the review findings of the re-click restore and the ledger lock #258 does for the API). Each outcome is one error_log line, never with a key or the buyer's details.

• The shared part is 202-config/PaymentNotification/, shaped by the coordinator's guidance:

  • ProviderAdapter: stored secrets, verify, parse.
  • Notification: kind sale|rebill|refund|chargeback|test|ignored, the provider's event, transaction id, the original transaction id, amount, currency, click id, occurred-at.
  • Processor: records or reverses through p202RecordLegacyConversion().
  • Response: the one mapping from outcome to status and body.
  • Receiver: method, verify, parse, process, log.

  PayKickstart is PaymentNotification\PayKickstart\{PayKickstartAdapter, PayKickstartSignature, PayKickstartKeys}. There is no request log, queue, secrets store or UI framework.

• Keys:

  • Storage. 202_users_pref.paykickstart_ipn_secret_keys (text, one key per line), in the table definition and the 1.9.78 → 1.9.79 rung. usersPref() is added to the rung's single _upgrade_measurement_tables() call, because UpgradeLadderTest refuses a second call.
  • Validation. PayKickstartKeys: at most 20 keys, each 8 to 128 characters of visible ASCII other than the comma. "" clears them. A bad key is refused by its place in the list, never by its text.
  • The page. Account › API integrations adds and removes keys one at a time. It shows only the last 4 characters of each key. A remove names the key by its place and by an HMAC-SHA256 of the whole key under a secret the session holds server-side (8532b44, Codex's P2), so a list changed in another tab removes nothing, including a different key with the same ending. Before 8532b44 it carried the ending, which that other key matched.
  • The API. PUT /users/{id}/preferences paykickstart_ipn_secret_keys replaces the whole list. The Go CLI's user prefs update --paykickstart-ipn-secret-keys sends it.
  • Never served. Since the merge of 1.9.79: GET /users/{id}/preferences serves no integration secret #270, GET /users/{id}/preferences answers the column as {"stored": true}, as it does every integration secret (ServedPreferences::SECRET). A GET body sent back keeps the keys. The count this PR first served in its place (paykickstart_ipn_keys_stored) is gone: one shape for every secret, and no second key for one column that PUT would have to accept back. GET /system/integrations still has keys_stored (how many) and a real secret_stored. Staging a write that carries the keys is refused (pinned in StagedChangesControllerTest). There is also a Slack notice when the keys change.

• The panel gives the vendor steps, including setting the campaign's "When a click converts more than once" to "Add them up" for subscriptions. In the live pass, "Keep the latest" made each rebill replace the sale's value. The panel also has the affiliate note.

• Docs and changelogs: docs/openapi.yaml (integrations, preferences, the ledger source enum), docs/cli.md, docs/cli-agent.md, documentation/api/{09,10,14,15}, documentation/cli/{10,12}, a PayKickstart section with an outcome table in documentation/tutorials-and-guides/09-3rd-party-integrations.md, changelogs.txt and changelogs.json.

The machine check for the defect

tests/Release/HandedOutUrlsNameServedFilesTest checks that every string literal in a served PHP file naming a script under tracking202/ or a 202-* directory names a file that exists, and that every integration AdministrationController::INTEGRATIONS lists does too. KNOWN_DEAD (jvzoo.php, zpn.php, slack.php) only shrinks: a listed file that appears, or that nothing names any more, fails the test. Planted and caught: a dead script in INTEGRATIONS, a dead script on the page, and a dead entry removed from the list.

Other structural tests taught about the new code:

• PostReadersCheckTokenTest: the endpoint reads $_POST and is authenticated by HMAC.
• StoredVisitorIpSourceTest: the Processor's ip is the provider's server, as in cb202.
• WebEventPathsTest: it could not see a recorder called through a class, so it now counts an endpoint that builds the Receiver as recording, and the endpoint is listed as exempt. A planted removal of the exemption fails.

Decisions a reviewer should check

1. Verification is against every account's keys, not "look up the click's owner, then try its keys". The brief proposed the second; the coordinator's interface fits the first. Reasons:
   • An IPN with no custom_subid (a test ping, an untracked sale) can still be verified and acknowledged.
   • The click is looked up only after a key verified, so the endpoint is no oracle for click ids to anyone without a key.
   • To a key holder, another account's click answers exactly like a click that does not exist.
   • When two accounts store the same campaign key (one product, two Prosper202 users), the click decides between them.
2. PayKickstart's signature joins values with "|" and leaves the field names out, so it is not injective (CLAUDE.md [Config] Update PHP version checks #17). Whoever holds one signed IPN can move its values between field names, and can add fields whose value is empty or "0", without changing the hash. No receiver can close that. The adapter reads every field it uses strictly, and the docblock, the panel's docs and this PR recommend an https IPN URL.
3. Lists (licenses with several licences) are left out of the signed string. This was executed, not inferred: PayKickstart's PHP validator, run verbatim on PHP 7.4 (unpacked from the ondrej PPA), drops an array value and gives the same hash as the payload without it. On PHP 8 the validator throws TypeError.
4. Non-ASCII text. The conversion to ISO-8859-1 is written out rather than left to iconv(), whose //IGNORE varies by C library. It equals glibc iconv on every valid string tried (3,000 random strings in the test, 20,000 in the scratch run).
   • PayKickstart's JS sample signs UTF-8 bytes, and its (truncated) Python sample drops non-ASCII characters. If PayKickstart's real signer followed either one, an IPN from a buyer named "José" would be a 403.
   • The PHP sample, the one with the explicit conversion, is the reading taken. Nothing PayKickstart signed has been seen.
5. Refund amount. PayKickstart does not say which amount a refund IPN carries. A positive amount reverses that much; none (or 0) reverses the whole sale; a minus sign is dropped.
   • The refund carries no id of its own, so it is keyed by its body (b000000). Only the same notification sent again finds a reversal already on file, standing or deleted, and it is 200 duplicate.
   • Any other refund of a sale with a standing reversal is compared with that reversal. It is 200 duplicate when it takes back what that reversal took back; a refund with no amount (or 0) counts as the sale's whole amount. Otherwise it is a 409 naming both amounts, so a full refund after a partial one says what was reversed and how much is still credited (Codex's P1, cf1bd2a). A sale is reversed once: nothing in PayKickstart's IPN documentation, as read for this PR, describes cumulative refunds.
   • Once the standing reversal is deleted (the refund was undone), a later refund reverses the sale again. Before b000000 every refund without an id shared the key rev:<sale>:1, which the deleted row keeps, so the next refund was answered 200 duplicate and reversed nothing (measured on the JVZoo branch).
   • The writer still decides under the click's lock whether a reversal is written (Fix undefined array key warnings and TypeError in aff_campaigns.php #36). The Processor's reads afterwards only choose between duplicate and 409. A refund with an id of its own (none from PayKickstart) is still told apart by that id.
6. A conversion is dated by the time the IPN states (be2dd5c, Codex's second P1). PayKickstart retries a failed delivery up to 13 times, and the row used to be dated time().

   • Signed. transaction_time is covered by the signature, like every non-empty field. Decision 2 still applies: a holder of a signed IPN can move values between fields, but cannot set a time of their own.

   • Unreadable. A time that is not a Unix time is a 400 naming it (subid missing in pixel url #4), where it used to read as no time. With none stated, the row is dated when it arrives.

   • Bounds. The time is held between the earliest it can be and its arrival, and the answer and the log line say so:

     • for a sale, the earliest is the click it credits (its latest visit, the one the ledger credits);
     • for a refund, it is the sale it takes back, so the sale keeps its own day and the refund lands on its own;
     • a time ahead of this server's clock is dated at arrival.

     These are held rather than refused: refusing would lose the payment over a clock, and PayKickstart would resend the same time.

   • Repeats. A repeat is not compared by its time, only by its amount. The stored time may be a bound rather than the time sent, so the comparison would refuse a genuine retry.

   • Reports. p202 report counts a conversion on its click's day and is unchanged by this. What moves is everything by conversion time: the conversion list and its time filter, attribution, and the click-to-conversion time.

7. A deactivated or deleted account's stored keys still verify, as every other postback endpoint records for any campaign owner. An IPN is PayKickstart reporting a sale, not the user acting.
8. No traffic-source postback is fired for a PayKickstart conversion, matching cb202 (p202RecordLegacyConversion() has no notify_traffic_source).
9. Processor refuses a notification that states a currency other than the account's (422). No adapter sends one yet; this is the default for the next adapter, tested by building a Notification directly.
10. A sale sent again after its refund is a 409, naming the reversal to delete if the refund was undone. This was ported from the JVZoo branch, where JVZoo documents an undone refund as RFND and then SALE again.
    • It is the answer for PayKickstart too. PayKickstart's IPN documentation, as read for this PR, describes no undone refund, so a sales IPN for a reversed sale is either a late retry of a sale already answered, or a sale PayKickstart says counts again.
    • A 409 leaves one error in PayKickstart's IPN log and changes nothing. A 200 would hide the second case.
    • Once the reversal is deleted, the sale counts and the same IPN is 200 duplicate.
11. The 403 names the provider's signature field through ProviderAdapter::signatureField() (hash for PayKickstart).
12. What the JVZoo and ClickBank adapters need when they merge this:
    • signatureField();
    • the payment's own time in Notification::$occurredAt, refusing one they cannot read (400 naming the field) rather than leaving it null. The Processor does the rest.

Verification

Scope report of .claude/skills/p202-verify/scripts/verify.sh --since origin/1.9.79 --changed, on 8532b44, after the merge of 1.9.79 at 915a367 (#270, #280, #281, #282) into this branch (PHP 8.3.6, MariaDB 10.11, full vendor/; the unit tier ran 6164 tests), verbatim:

Scope report
------------
  go         PASS  ran under CI's go1.25.14 via GOTOOLCHAIN (local go is 1.24)
  golangci   PASS  ran under CI's go1.25.14 via GOTOOLCHAIN (local go is 1.24)
  openapi    PASS
  patterns   PASS
  phpcs      PASS
  phpstan    PASS
  schema     PASS
  syntax     PASS
  unit       PASS

Not covered by this script:
  live      stand up an instance, drive the path a user would take
  agent     add and run a case under tests/fixtures/agent-eval/cases/
  ci        a workflow still in_progress has not passed; read the run

Run by hand, beyond the ladder:

• Integration suites, each alone on a database created for it, as CI's integration job runs them:
  • tests/PaymentNotification/PayKickstartIpnIntegrationTest (20 at 41bfe59, 13 at first): sale, replay, a replay stating another amount, rebill, subscription-payment, full and partial refund, refund replay, a second refund (409), a refund with nothing to reverse (404), a bad hash, a tampered amount, a missing hash, GET, another account's click, a click that does not exist, a key shared by two accounts, test mode, an ignored event, no subid, a malformed amount, an unreadable stored key, a currency the account does not count in, and the 503 while the upgrade is pending; since cf1bd2a and b000000, a full refund after a partial one, a repeat however its amount is spelled, a sale stated again after its refund, a refund after its reversal was deleted, a refund with an id of its own, a sale and a refund days late (dated when they happened, a refund before its sale dated at the sale, a changed time a 403), and a time before the click or ahead of the clock (held, and said).
  • tests/User/PreferencesWriteIntegrationTest (6), tests/Api/V3/AccountAdministrationIntegrationTest (13), and 1.9.79: GET /users/{id}/preferences serves no integration secret #270's tests/User/PreferenceSecretsAreNotServedIntegrationTest (5), whose round trip now stores the PayKickstart keys with the other secrets.
  • Every integration suite, through CI's own tests/run-integration-suites.sh on the merged tree: 142 suites, 1340 tests passed, and 2 suites failed. Each of the 2 was then re-run alone on a fresh database:
    • AttributionWorkerIntegrationTest passed 3 runs of 3. In the full run, its dead-connection lock test (the dead session took its lock with it) had failed while other sessions were using the same server.
    • MysqlLookupRepositoriesIntegrationTest fails one test, testTheFactoryCachesThroughTheBootstrapHelpers, with Class "Memcached" not found: this sandbox has no memcached extension, and CI's job installs it.
• Signature vectors were computed independently by PayKickstart's PHP validator run verbatim (PHP 8.3 and PHP 7.4 agree) and by a separate Python reading of its steps. The payloads are the docs' example, the same fields reversed, "0" and empty values, non-ASCII text, whitespace, a "|" in a value, a refund under another key, a list value and a single licence.
• Planted defects, each caught by a named test failing:
  • dropping the owner check, the duplicate-amount compare, the reversal-amount compare, the key check, test mode, or the currency refusal;
  • signature changes: "0" kept, no trim, no Latin-1, no sort, a list cast to text;
  • adapter changes: a negative sale accepted, a malformed subid read as no click, is_rebill read loosely;
  • keys changes: the 20-key limit dropped, keys served by withoutKeys() (since removed for 1.9.79: GET /users/{id}/preferences serves no integration secret #270's shape), GET preferences serving the keys, integrations counting no keys;
  • the three URL plants, the missing exemption, and the Go flag missing (TestPrefFlagsMatchThePreferenceRules).
  • since b000000, in the Processor:
    • no live-reversal check on a sale;
    • an id-less refund keyed 1 again;
    • no comparison with the standing reversal;
    • a refund compared only when it states an amount;
    • an own-id refund compared with the standing reversal.
  • since be2dd5c, the dating:
    • the pushed Processor;
    • the recorder ignoring conv_time;
    • a time ahead of the clock taken as sent;
    • a time before the click taken as sent;
    • a refund held to the click instead of its sale (first missed, then caught by a test added for it);
    • an unreadable time read as none (5 adapter cases).
  • since 8532b44, the key's Remove: the pushed removed() (which compared the ending), and a token computed from the ending alone.
  • The stacked branch. 1.9.79: PayKickstart's product IPN, verified with each campaign's key #268 at b000000 merged into 1.9.79-jvzoo-ipn with no conflicts (git merge-tree). On that merge, with signatureField() added to the JVZoo adapter, JVZoo's four suites passed (14 IPN integration tests, 54 unit tests), and so did PayKickstart's IPN suite. At aab3909, which includes 1.9.79: the findings of the 1.9.78 release's adversarial review #262, the only conflict is changelogs.json, between 1.9.79: the findings of the 1.9.78 release's adversarial review #262's lines and JVZoo's line. Not rechecked at 41bfe59.
• tests/live/upgrade-equals-install.sh (1.9.55 on PHP 7.4 → this branch, against a fresh install): 25 passed, 0 failed. 162 tables are identical, and the upgrade logged nothing.
• Upgrade from the latest tag: v1.9.78 installed with its own installer, then upgraded through upgrade.php with this branch. 202_version reads 1.9.79, paykickstart_ipn_secret_keys text NULL was added, and no upgrade log line appeared.
• Live pass on an instance installed with install-instance.sh and seeded with seed.sh:

  • Setup. Campaign B's offer URL was set to https://app.paykickstart.com/checkout/123?subid=[[subid]] (p202 campaign update). Two keys were stored with p202 user prefs update 1 --paykickstart-ipn-secret-keys …. user prefs get (before 1.9.79: GET /users/{id}/preferences serves no integration secret #270, a count) and system integrations showed the count and never the keys.

  • A click. Tracker B redirected to …/checkout/123?subid=7.

  • Again on the final tree. The IPN list below was run again on a fresh click, subid=9, after the merge of 1.9.79: the review findings of the re-click restore and the ledger lock #258 and the 503 commit, and gave the same answers.

  • IPNs. Signed with the published algorithm (a script independent of this code) and POSTed with curl. Results: sale 200 recorded, replay 200 duplicate, another amount 409, rebill 200, subscription-payment 200 ignored, test mode 200, full refund 200 reversed, its replay 200, a second refund 409, a partial refund 200, a refund of a sale not on file 404, a stranger's key 403, a tampered amount 403, no subid 200 no_click, custom_subid=[[subid]] 400, 1,000.00 400, another account's key on this click 404, the Affiliate IPN's JSON 415, GET 405.

  • Read back. p202 conversion list --source paykickstart and p202 click conversions 7 and 8 read the rows back. In accumulate mode, 47 + 9 − 9 = 47 was the click's value, and the campaign breakdown showed income 47. The server log held one line per IPN and no key, email or buyer name.

  • An undone refund, end to end (port 8230, b000000), each IPN signed and posted to paykickstart.php:

    • sale: 200 recorded; refund: 200 reversed (conversion 2);
    • the sale again: 409 naming conversion 2;
    • p202 conversion delete 2 --force, then the sale again: 200 duplicate;
    • a later refund: 200 reversed (conversion 3);
    • the first refund sent again: 200 duplicate, naming deleted conversion 2;
    • the later refund sent again: 200 duplicate;
    • the sale again: 409 naming conversion 3;
    • an IPN signed with no stored key: 403 naming hash.

    p202 click conversions read the rows back as +47, −47 (deleted), −47, and the click's value as 0.

  • A late IPN, end to end (port 8230, 41bfe59), on an instance set up without the licence stub (below) and driven by curl:

    • setup through the API: a campaign at https://app.paykickstart.com/checkout/123?subid=[[subid]], a tracker, and the key;
    • a click through dl.php, then backdated five days in the click tables (a fixture edit);
    • GET /users/1/preferences answered the keys as {"stored":true}, and /system/integrations keys_stored 1.

    The IPNs, each signed and posted to paykickstart.php:

    • a sale stated 3 days ago: 200 recorded, dated that day;
    • its refund stated 2 days ago: 200 reversed, dated that day;
    • a sale stated before the click: dated at the click, saying so;
    • a sale an hour ahead of the clock: dated at arrival, saying so;
    • transaction_time=2026-10-25: 400 naming it.

    The read-backs:

    • GET /conversions?click_id= (behind p202 conversion list) showed the four rows on 10-25, 10-26, 10-23 and 10-28;
    • GET /conversions for the sale's UTC day listed the sale alone;
    • GET /reports/timeseries?interval=day (behind p202 report timeseries) counted the conversion on the click's day, 10-23, as before.

  • The page. A second account signed in and, through the page's own forms (token included), added a key, was refused a 5-character key ("The key is 5 characters long; …") and a duplicate, had a stale remove refused, and removed a key. The key's text never appeared on the page.

• Agent eval. New case admin-005-a-paykickstart-key-is-stored-never-repeated: store a campaign's key and give the URL to paste.
  • Run (before 1.9.79: GET /users/{id}/preferences serves no integration secret #270). With the reference agent against the live instance, all five mechanical expectations passed: user prefs update was run, keys_stored is 1, the preferences read leaves out the key, and the reply has the URL and subid=[[subid]] but not the key. The rubric was graded by hand from the judge's input, because no judge runs here.
  • Planted. An agent that stores nothing and repeats the key failed four of the five: the command, both checks, and the reply's omission of the key. The fifth passed because its reply did carry the URL.
  • Search. p202 search puts system integrations first for this ask and user prefs update second: the ask holds two tasks. It is listed in searchKnownMisses rather than taught by a phrase taken from the ask.
• Browser pass (node tests/browser/run.js --spec account-pages, new scenario added): the PayKickstart scenario passed all 8 checks, and every Account page passed its baseline at 1280px and 390px in light and dark. One existing scenario failed, "a DNI network is removed only when confirmed", because the pass signed in as a second admin. The page lists user 1's DNI networks but deletes only the session user's. That is not caused by this PR; see below.

Could not run

• CI has not been observed yet.
• The licence stub has been down since the machine restarted on 10/28, so install-instance.sh fails at the licence step:
  • The 41bfe59 instance was set up with the installer's own steps (install_databases(), InstallAccount::create(), a REST key) without the licence form.
  • The Go CLI is refused there (402), so p202 report, p202 conversion list and the eval case did not run against it. Their API endpoints did, by curl. The earlier passes in this PR ran with the stub.
  • The eval case now checks {"stored":true} (updated for 1.9.79: GET /users/{id}/preferences serves no integration secret #270) and has not been run since.
  • The signed-in pages need the licence too (they redirect to api-key-required.php), so 8532b44's Remove form was not driven in a browser or over HTTP. PayKickstartKeysTest covers the stale form, both before and after, and the page's own change is the form field and the handler's argument.
• One integration test needs the memcached extension, which this sandbox lacks (above).
• The eval case's rubric was graded by hand, not by a judge command.
• The pass ran on MariaDB 10.11, and CI runs MySQL 8.0.
• No real PayKickstart IPN was available. Every hash checked here was computed from PayKickstart's published validator, so a divergence between their docs and their signer (decision 4) would show only in production.

Found outside this item

• GET /users/{id}/preferences served the older secret columns in plain text (cb_key, jvzoo_ipn_secret_key, zaxaa_api_signature, ipqs_api_key, the Slack URL, lpo_bridge_config); 1.9.79: GET /users/{id}/preferences serves no integration secret #270 has since fixed it.
• Account › API integrations lists 202_dni_networks WHERE user_id = '1' but removes WHERE user_id = <session user>. An admin other than user 1 sees user 1's networks, and their Remove answers "not found".
• Amount::toUnits() accepts 13 whole digits while conversion columns are decimal(11,5). MariaDB under the empty sql_mode that connect.php sets clamps 5000000 to 999999.99999 with only a warning; that was measured on the column, not through an endpoint.
• PayKickstart and ClickBank conversions fire no traffic-source postbacks (p202RecordLegacyConversion() has no notify_traffic_source), unlike gpb.php.

---

Generated by Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-28T13:43:03.075517Z We couldn’t complete this review. Comment @codex review to try again.	9f00e63	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

Code review: CLEAN

For 658a28e: 0 issue(s). The review is encrypted for the maintainers in the review-findings artifact of this run.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 658a28e74e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Adversarial review: NON-BLOCKING

For 8532b44: 4 finding(s). The report is encrypted for the maintainers in the review-findings artifact of this run.

Rewritten on every push; the check fails on BLOCKING.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: aab39091fe

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 41bfe59e82

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 80d1bc4742

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Make key-list updates atomic

When two sessions for the same account submit overlapping key changes, both requests can derive $pkKeys from the same $pkOld and then blindly replace the whole column, so the last write discards the other session's addition or removal; for example, concurrent additions of keys A and B can leave only B stored, causing IPNs signed with A to be rejected. Fresh evidence beyond the earlier stale-token issue is that the full-list write here has no row lock or compare-and-swap check; update the list transactionally or condition the update on the previously read value.

Useful? React with 👍 / 👎.

[tracking202]

The lost update is real. Two sessions of one account that save the key list at the same moment each write the list they read, so the later save drops the other's change.

I'm not fixing it only here, because every settings form on API integrations and the other Account pages works the same way: it posts whole values and rewrites them, so any two concurrent saves of one account's settings lose one. A compare-and-swap on this one column would leave every sibling form with the same shape (CLAUDE.md #5). The proportionate fix is page-wide: each settings form carries the version of what it showed and refuses a save over a newer one. I'm filing that as one follow-up for the owner rather than widening this PR.

The window is one account saving its own PayKickstart key list from two places within the same request round-trip. The visible outcome is an IPN refused for an unknown key, and that is logged with the key's prefix.

---

Generated by Claude Code

[tracking202]

Correction to my last line: an IPN signed with a dropped key isn't logged with the key's prefix. When no stored key verifies the hash, the adapter answers the notification as unverified and logs no key at all. So the visible sign is a run of unverified IPNs for that product, not a named key.

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.