← Practice Lab

PRACTICE PROJECT / GUIDED PROJECT

Payment provider integration

Define the contract, reconciliation and failure paths for a new payment service.

IntermediateFictional business scenarioReference approach included
Your task

Read the brief and work through the deliverables before opening the reference approach. Your notes stay in this browser only.

Company context

A fictional subscription company needs a second payment provider for resilience.

Business problem

The current provider has outages; the business wants failover without duplicate charges.

Stakeholders

  • Customers
  • Payments operations
  • Finance
  • Security
  • Product
  • Engineering
  • Provider

Stakeholder interviews

  • Finance: “We need daily settlement traceability.”
  • Engineering: “Callbacks may be duplicated or late.”

Existing process

  • Create invoice
  • Request payment
  • Receive provider response
  • Update subscription status
  • Reconcile settlement

Business rules

  • A single invoice must not be charged twice.
  • A subscription activates only after confirmed payment.

Customer feedback

  • “I was charged but the app still said payment pending.”

Sample data

  • Provider outages occur monthly
  • Manual reconciliation takes several hours

Constraints

  • PCI scope remains unchanged
  • No double charge
  • Rollback path required

System / API information

The provider exposes create-payment and status endpoints plus asynchronous webhooks; IDs and errors differ from the current provider.

What would you deliver?

  1. Map API fields and status states
  2. Define authentication, retry and idempotency
  3. Write UAT scenarios
  4. Define reconciliation ownership
  5. Plan phased release

Your working notes

Draft an approach here, or work offline. Notes are stored locally in your browser—not sent to a server.

View reference solution / my approach

This is one defensible approach, not the only correct answer. Compare the reasoning and trade-offs with your own work.

Define

Why: The contract must include asynchronous and ambiguous states.

Deliverable: Field map, status model, retry and idempotency rules.

Validate

Why: Happy-path testing misses the most expensive failures.

Deliverable: Duplicate callback, timeout, delayed success and provider-outage tests.

Release

Why: Payments need a controlled fallback and clear ownership.

Deliverable: Phased rollout, monitoring and reconciliation runbook.