Authorize.Net payment link app — admin panel + hosted payment form (full spec & design provided)

Our company sells premium humidors and cigars. A meaningful share of our orders arrive by email or phone, and we currently have no clean way to take card payment for them. We need a small, well-built web application in two parts: 1. An internal admin panel where an authorised administrator enters an order number, description, amount and customer email, and sends the customer a secure single-use payment link. 2. A branded hosted payment form where the customer enters their own card and billing address and pays. Processing is through Authorize.Net. Company staff must never see, type or store card data. We use Accept.js, so the card goes from the customer’s browser straight to Authorize.Net and our server only ever holds an opaque token. Target scope is PCI SAQ A-EP. There is a strict three-role model, and it is the core of the project: Super Admin — creates, blocks and unblocks users. Cannot create payment links. Administrator — creates and sends payment links. Every link is stamped with their name. Agent — views payment status and resends a link a customer has lost. Cannot create a link or change an amount. Role separation must be enforced server-side on every endpoint, not by hiding buttons. 2FA is mandatory for all three roles. What you get on day one: A 12-page technical specification: flows, role matrix, field-level validation, data model, gateway configuration, security requirements and acceptance criteria (attached) Complete UI design for all five screens, in HTML (attached) All interface copy, error messages and email content Our Authorize.Net sandbox and production credentials What we need from you: the build, the gateway integration, hosting setup, security implementation, testing and handover. Nothing to design, nothing to write, nothing to specify. Stack: your choice, as long as it is mainstream and maintainable — Node/TypeScript, Laravel or Django, with PostgreSQL or MySQL. No Shopify dependency: we run a Shopify store and order numbers come from it, but the order number is typed in by hand and the app must stand alone. Full source code and IP transfer to us on completion. Please read the attached spec before applying, and answer the screening questions specifically. Generic proposals will not be reviewed. Scope in one list: Auth: email + password + mandatory TOTP 2FA, self-service password change and reset, Argon2id/bcrypt, breached-password check, lockout, session management User management (Super Admin only): invite by email — the user sets their own password and 2FA, never an admin; change role; block/unblock with instant session termination; force password reset; reset 2FA; soft delete Payment link creation (Administrator only): validation, confirmation step, configurable expiry, immutability after send Payment link list (all roles, actions by role): filters, search, CSV export, detail drawer with attempt history, AVS/CVV results and transaction ID Hosted payment form: branded, responsive, Accept.js tokenisation, mandatory billing address for AVS, idempotent submission, branded states for expired / paid / cancelled / not found Authorize.Net: authCaptureTransaction , eCommerce market type, AFDS + AVS + CVV filters, heldForReview handling, 3DS where the account supports it Webhooks: signature-verified, idempotent, authoritative for payment status Transactional email via SendGrid/Postmark/SES: 7 templates, SPF/DKIM/DMARC setup Audit log: every user and link action with actor, IP and timestamp Deploy to pay.our-domain, TLS, backups with tested restore, error tracking with card-data scrubbing Written statement of the PCI SAQ level your architecture achieves 30 days of bug-fix warranty and a recorded handover Acceptance is objective. The spec lists 17 acceptance criteria. Among them: an Agent session must be rejected when it calls the create-link endpoint directly; double-clicking Pay Now must produce exactly one charge; a deliberately mismatched ZIP must be declined by AVS; a replayed webhook must not duplicate a record; and a network trace must show that no card data ever reaches our server. Screeneing questions: 1. Have you integrated Authorize.Net before? Which product — Accept.js, Accept Hosted, or the direct API — and please link to a payment page you built that is live today. 2. Walk me through where the card number travels in your proposed architecture, from the customer’s keystroke to Authorize.Net. Be specific about what our server receives. 3. Which PCI SAQ level would your proposed build qualify for, and why? 4. An Agent-role user copies their session token and calls the “create payment link” endpoint directly with curl. What happens, and where in your code is that decided? 5. A customer double-clicks Pay Now and their browser retries the request. Separately, Authorize.Net redelivers the same webhook three times. How does your build avoid a double charge and a duplicate record?