UltraTechEffect

## the-problem

## the-approach

• ▸split the card journey in two: a Stripe SetupIntent at post-job time authorises the card without taking a cent, and the payment method id is stored on the employer alongside their Stripe customer id
• ▸put the charge where the value is — the apply handler creates an off-session, auto-confirming PaymentIntent against that saved card, so the invoice is generated by the applicant rather than by a calendar
• ▸kept the coaching side conventional: an attended PaymentIntent, its client secret returned to the browser, confirmed against Stripe Elements with the buyer watching
• ▸stored each job's address as a GeoJSON point at save time, so "jobs near here" is a radius query rather than a string match on a city name
• ▸layered the facets on top — employment type, seniority and salary band — over the same query the map and the list both read
• ▸gave employers a portal built from their own records: posts, applications and views bucketed by day over a rolling week
• ▸transformed uploads on the way to S3 — full-size and a 400px thumbnail written in one pass, so no resize job runs later
• ▸provisioned the whole box in Terraform — VPC, subnet, gateway, security group, EC2 — with cloud-init installing nginx, certbot, Node and pm2, and a self-hosted Actions runner doing the redeploy

// Post-job. The employer is present, and nothing is charged:
// a SetupIntent just proves the card is real and stores it.
export const saveCard = async (req, res) => {
  const user = await User.findById(req.userid);
  const intent = await stripe.setupIntents.create({
    customer: user.employerProfile.payment.customerId,
    payment_method_types: ["card"],
  });
  res.send(intent.client_secret);   // confirmed in the browser
};
 
// Weeks later. A candidate hits apply — the employer isn't here,
// there's no page to challenge on, so it has to go through
// unattended or not at all.
export const applyToJob = async (req, res) => {
  const job = await Job.findById(req.params.id);
  job.appointments.push({ userData, schedule, resume, appliedBy });
  await job.save();
  res.send("Applied");
 
  if (job.isAdminJob) return;         // house listings bill nobody
  const employer = await User.findById(job.postedBy);
  chargeCustomer(
    19,
    employer.employerProfile.payment.customerId,
    employer.employerProfile.payment.activeCard,
  );
};
 
const chargeCustomer = (amount, customer, payment_method) =>
  stripe.paymentIntents.create({
    amount: amount * 100, currency: "usd",
    customer, payment_method,
    off_session: true, confirm: true,   // nobody to prompt
  });

## the-architecture

## the-results

• ✓billing follows applicants, not listings — an employer with no response pays nothing, and the charge is raised by the apply handler itself
• ✓one account model carries both an unattended card-on-file charge and an ordinary attended checkout
• ✓"near me" is a real geo query: points in, radius out, with the facets applied over the same result set
• ✓the environment is reproducible — the VPC and instance are Terraform, the box's setup is cloud-init, and a push to main redeploys it
• ✓what I'd change, and it's the same flaw three times over: that unattended charge is fire-and-forget. It isn't awaited, its rejection is only logged, no record of it is written against the application, and it carries no idempotency key — so a card that fails off-session (which is the normal outcome when the issuer wants 3-D Secure) loses the money silently, and a retried apply request bills twice. It belongs in a charges collection written in the same step as the application, keyed on the application id, with a Stripe webhook reconciling the outcome and a retry path that emails the employer to re-authorise.
• ✓and the amount is hardcoded rather than read from the employer's package, so the tier the pricing page sells isn't the tier that bills