MJos Predictive Model | First manifestation of the Bangel Language
New project sequence ยท proposed bindings
Merchant onboarding, checkout creation, payment status and webhook handling at the BarTide payment boundary.
BarTide Stripe API / Blue MJos Predictive Model | First manifestation of the Bangel Language MJ Physics Engineering | Owned and operated by Michael Bangel | Clearwater, Florida PROJECT REFERENCE Merchant onboarding, checkout creation, payment status and webhook handling at the BarTide payment boundary. OBSERVABLE BEHAVIOR - Connected-account onboarding, restaurant checkout/tracking/cancel endpoint, snapshot and thin webhooks. - Merchant provider source uses idempotency keys, metadata binding and returned-payment/refund reconciliation. - Current MerchantPaymentOptions hard-codes environment test and accepts rk_test restricted keys; checkout requires onboarding flag, checkout flag, cards-only verification and both webhook secrets. TYPED CONTRACT - MerchantEnvironment: test - PaymentIntentBinding: tenant + order + account + attempt + amount + currency - ProviderEvidence: signed event + retrieved object - SettlementStatus: pending | paid | refund state DECISION RULE Record only the reconciled payment state; absent provider evidence remains pending/HOLD. CONSUMER RULE Read the result status before interpreting its value. Preserve the tenant, project, source version and evidence context. Do not treat a missing record, an unexecuted proposal or a successful computation as an authorized external action. EVIDENCE LIMITS - Do not describe merchant source as enabled live payments. - Production secrets, provider account readiness and successful real payment flow were not inspected. - Signed webhooks are provider evidence, not blanket permission.