Payments + Integrations Engineer
Location: []
Payments & Financial Systems Engineer (Event-Driven, Ledger-Based) (Financial Systems / Event-Driven Architecture) Mission Build and connect a deterministic, event-driven payments system to MyBnBCollection’s booking engine, with no manual overrides, no balance mutation, and full auditability. You are not building “features”. You are building financial truth. Core Responsibilities Integrate a payment processor (Stripe preferred) with an existing booking engine Implement webhook-driven money ingestion Build event ingestion → engine dispatch → ledger posting Ensure idempotency and double-entry accounting Implement SARI, NORA, and FLOWS boundaries Guarantee refunds and credits follow policy, not human decisions Produce auditable, regulator-safe financial logs What You Will NOT Do ❌ No manual balance edits ❌ No admin overrides ❌ No “fix it in the database” ❌ No user-specific exceptions If it can’t be done with an event, it does not exist. Required Skills (Non-Negotiable) Payment processors (Stripe or equivalent) Webhooks & retries Idempotency keys & replay safety Ledger-based accounting (append-only) API integrations Failure-mode thinking Comfort saying “no” to business pressure Nice to Have Experience with marketplaces Familiarity with refunds & chargebacks Financial compliance awareness Experience with WordPress as frontend only. Stripe, Webhooks, Event-Driven Architecture, Ledger Accounting, Marketplace Payments, Financial Systems, Idempotency, Refund Processing, Subscription Billing, Audit Trails. Very Important: Marketplace Payments Subscription Billing Credits / Loyalty Systems (Non-Cash) Distributed Systems Concepts Idempotent Processing State Machines Security Best Practices. Useful: WordPress Integration (Headless / API-based) RESTful APIs Webhook Security (Signatures, Retries) Cloud Services (AWS / GCP / Azure) Testing Financial Systems System Design. you will also: encode governance as policy-as-code ensure outcomes are: deterministic idempotent immutable enforce: no manual overrides append-only logs rule versioning guarantee: “If the rule says X, the system can only do X.” build: rule engines constraint APIs preview endpoints: GET /preview/outcome?action=cancel&booking_id=... evidence logs: rule version timestamp consent hash This is how outcomes are shown before action.