Recovering Registration and Payment Journeys on a Sports Platform

Ampity resolved customer-facing registration and payment issues, then expanded into product engineering, AWS delivery and production support for a live sports platform.

[Problem] A payment could succeed while its registration record was missing

Families using a sports platform encountered slow pages, registration problems and duplicate charges. Some had paid but could not find the corresponding application record. For the organizations running registration, a payment receipt and a missing application created a problem that could not be solved by making the interface look better.

Ampity began with two engineers focused on these customer-facing failures. The engagement later grew into broader responsibility for product and project management, frontend and backend development, QA, integrations, AWS engineering and operations. This historical case describes that recovery and the engineering foundation behind it. The customer remains unnamed here to preserve confidentiality.

The starting point was an application already in use. Changes therefore had to address families' immediate problems while keeping the platform available for ongoing work. The account describes critical issues being resolved and new capabilities being delivered; it does not provide an incident-by-incident timeline or a measured registration-completion rate.

[Priority] Follow the customer journey before choosing infrastructure

The recovery focused on loading, registration, payments and the records those payments should create. Ampity investigated the underlying problems, corrected critical issues and looked for related failures that had not yet been reported. That expanded the work beyond closing isolated tickets.

The important boundary was between a visible symptom and a complete customer outcome. A faster page would not resolve a duplicate charge. A successful payment response would not establish that an application had been recorded. These were related parts of a journey that needed to be examined together.

The source does not identify a particular locking mechanism, idempotency implementation or reconciliation algorithm. Those should not be inserted into this account as if they were delivered. For another engagement, they are questions to investigate after understanding where payment, application and customer-visible status can diverge.

[Design] Separate static delivery, API work and persistent data

The documented platform used CloudFront with S3 for static web assets. Browser API requests reached API Gateway and .NET Lambda functions. Aurora MySQL stored relational data, with ElastiCache Redis serving the cache role. An identity server on EC2 handled authentication into the API layer.

The image reconstructs those logical responsibilities. It does not draw S3 forwarding application requests into API Gateway, or Aurora forwarding requests into Redis. Neither relationship is established by the customer story. The identity service is shown separately because the exact token-exchange protocol is not described.

[Delivery] Product changes and platform changes shared one plan

As the relationship developed, Ampity worked across frontend workflows, backend logic, APIs and integrations. The documented ecosystem includes card payments, ACH payments, invoicing, transactional email, marketing email and rich-text editing. Naming those integration categories does not establish that every provider call had the same failure or retry behavior.

AWS work covered platform data, automated builds, deployments, infrastructure provisioning and production support. CodePipeline coordinated source, build/test and deployment stages, with CodeBuild, CodeDeploy and CloudFormation recorded in the technical appendix. Those are historical implementation details, not a recommendation to copy the same pipeline into a new system today.

CloudWatch and X-Ray provided logs, metrics and tracing. IAM, Secrets Manager, KMS and Certificate Manager appear in the documented security inventory. Their presence does not establish regulatory compliance or prove that every permission was least privilege.

[Result] Recovery expanded into continuing engineering responsibility

The source records that critical customer issues were resolved, additional product capabilities were delivered and the application, AWS setup and release process were strengthened. The work expanded from the initial recovery into continuing engineering and operating responsibility.

The account covers recovery, product work and continuing operating responsibility. It does not establish a measured registration-completion improvement or a cost comparison with a defined baseline and observation period.

The outcome presented is the documented delivery scope and the recovery of critical journeys. It is not a guarantee that choosing Lambda prevents duplicate charges or that managed infrastructure eliminates application support.

[Review] What a similar platform should establish

For another registration platform, trace a completed registration through the browser, API, payment provider and persisted application record. Agree which record is authoritative and how support can explain a mismatch. Test interruption and retry behavior as separate acceptance scenarios rather than treating a successful API response as proof of the entire journey.

Review function concurrency alongside database connection limits. AWS documents the connection-management considerations for Lambda with RDS. This is guidance for a future review; the source does not establish that this platform used RDS Proxy.

Also review what happens when an external payment or email provider is unavailable, which evidence support staff can access, and how a release is reversed. Record the answers against the actual implementation before treating the diagram as an operating runbook. Discuss a live platform problem with Ampity.