live payment accounts — a real charge on Square and PayPal, as on Stripe

[mxfactorial]

A business connects its own payment processor, and every sale, refund and payout posts to its books
from the processor's webhook (modules/payments: configure_webhook, ingest_stripe,
ingest_square, ingest_paypal). The connect playbooks are live-first:

• Stripe — live today on gradientERP's own gerp: restricted live keys (stripe_setup for the
  webhook, stripe_billing for collection), live charges ingesting and posting
• Square — a production access token, rotated after the webhook is registered
• PayPal — live app credentials, kept standing, because every webhook verification calls back
  with them

where it stands (read 2026-09-12)

• connected, in June: gradientERP's own gerp holds Square's production token and webhook signing
  secret (stored 2026-06-04) and PayPal's live client id, secret and webhook id (2026-06-07); both
  ingest lambdas call the production hosts (connect.squareup.com, api-m.paypal.com), where a
  sandbox credential cannot connect. Each ingest last ran on 2026-06-08.
• not proven: no Square or PayPal event is in the webhook log (it holds Stripe's three charges),
  nothing from either is dead-lettered, and none of the ledger's 161 entries comes from either.
  A real charge on each has not posted.

the work

• a real charge on Square, and on PayPal, to gradientERP's own accounts — watch the webhook
  arrive, the event land in the log, and the entry post
• whatever the first real payload turns up, fixed in that provider's transform with a test
  pinned to the payload's real shape

done when

A real charge on each of Square and PayPal arrives by webhook, is ingested, and posts to the ledger
— as a Stripe charge does today.