Security weaknesses reached a business-critical system
The incident showed that infrastructure, application and payment controls needed to be treated as one connected risk surface.
Case Study 05 · Security · Payments · eCommerce
Payment Gateway & Security Modernization
Strengthening a business-critical US eCommerce environment after a security incident while engineering secure storefront and backend payment workflows, administering payment platforms, and owning the PCI compliance process.
Security Hardening
Braintree
CyberSource
PCI
01 · Executive overview
The project began with security risk and became a broader modernization of how the business accepted payments.
A security incident exposed weaknesses in the eCommerce environment and created an immediate need to review infrastructure, access, payment handling and operational controls. The work required more than restoring service: the business needed a safer checkout path, stronger server controls and a repeatable way to validate its security posture.
I worked across both the engineering and administrative sides of the payment environment. On the technical side, I implemented Braintree and CyberSource integrations, built a secured C# backend for phone-order charges and refunds, handled encryption, API/SDK integration, key exchange, SSL and fraud controls. On the administrative side, I managed developer portals, permissions, privileged users, fraud configuration and the PCI compliance process itself.
That compliance work included studying the PCI DSS requirements, completing the PCI DSS Self-Assessment Questionnaire D and Attestation of Compliance for Merchants, preparing for ASV scanning, configuring the in-scope server IPs, remediating findings and working through the scan process until the environment produced passing PCI evidence.
Secure storefront, phone-order and refund workflows
Braintree and CyberSource supported customer checkout plus controlled backend charging and refund operations inside a secured C# application.
Own the payment environment beyond the code
Developer portals, admin access, fraud configuration, SAQ D, AOC and ASV evidence were treated as part of the system—not paperwork after development.
02 · Business challenge
Payment security had to improve without breaking the commerce operation that generated revenue.
The environment combined older eCommerce application technology with live payment processing and dedicated cloud infrastructure. Security improvements therefore had to account for application behavior, server exposure, payment provider configuration, operational users and the realities of a running production business.
The business needed to respond to a real security event rather than a theoretical compliance exercise.
Classic ASP and ASP.NET applications still supported revenue-generating workflows and could not simply be switched off.
Checkout and backend transactions required stronger separation, provider configuration and fraud/risk controls.
Dedicated servers, firewall rules and open ports required review and hardening.
Vulnerability scanning and remediation had to become part of the operating discipline around payment infrastructure.
Security changes still had to preserve successful checkout, authorization and operational payment handling.
03 · My role
Two sides of the same responsibility: secure payment engineering and payment-platform governance.
Security & payment engineering
Customer card charging
Configure and integrate the website payment flow so customer cards could be charged securely during checkout.
Phone-order charging
Build secured C# workflows for CSRs to charge cards for customers placing orders by phone.
Backend card refunds
Allow authorized users to process credit-card refunds from the same controlled backend application.
APIs, SDKs & key exchange
Integrate Braintree and CyberSource using provider APIs/SDKs, credentials and key-management workflows.
SSL & server hardening
Configure SSL on dedicated servers and strengthen firewall, port and infrastructure controls.
Encryption & fraud controls
Protect sensitive data and configure transaction-risk / fraud rules around the payment workflows.
Payment-platform administration & PCI compliance
Developer account administration
Manage Braintree and CyberSource developer portals, application settings and integration credentials.
Permissions & privileged users
Control users, admin authority and appropriate access to payment-provider accounts.
Gateway fraud configuration
Configure provider-side fraud and risk settings in addition to application-side controls.
SAQ D & Attestation of Compliance
Study the PCI requirements, complete the merchant Self-Assessment Questionnaire D and prepare the Attestation of Compliance.
Scan scope & remediation
Configure in-scope server IPs, review ASV scan findings, remediate issues and repeat scanning until the required result was achieved.
PCI reporting
Maintain formal compliance evidence including ASV scan attestation and HackerGuardian PCI reporting.
04 · Security & payment architecture
One secured payment environment supporting storefront, phone-order and refund operations.
Payment entry points
CustomerStorefront Checkout
Customer places and pays for an order online
CSRPhone Order
Authorized CSR charges the customer from the backend
OperationsRefund
Authorized backend refund against a prior card transaction
→
Secured application & infrastructure
ApplicationLegacy Storefront + C# Backend
Controlled payment workflows · encryption · transaction state
InfrastructureSSL + Hardened Dedicated Servers
Firewall · port control · secured production environment
FraudRisk & Fraud Configuration
Application rules + provider-side fraud controls
→
Payment providers
GatewayBraintree by PayPal
Website payment processing and provider administration
GatewayCyberSource
Backend charging / refund operations and provider administration
GovernancePCI / ASV Control Plane
SAQ D · AOC · HackerGuardian · ASV evidence
Everything in one controlled backend
Phone-order charging and card refunds were handled from the secured C# application rather than through ad-hoc external processes.
Provider administration is part of architecture
Credentials, permissions, privileged users, fraud settings and developer-portal ownership directly affect the security of the integration.
Compliance scope follows infrastructure
Server IPs, SSL, exposure and ASV scan scope had to be understood and configured correctly for PCI validation.
05 · Incident response & security hardening
Reduce the attack surface before treating payment integration as complete.
Security remediation involved the broader hosting and application environment, not only payment code. I worked with SecurityMetrics around the incident-response/compliance process and hardened dedicated servers across HorizonIQ and IONOS by configuring SSL, reviewing firewall policy, restricting exposed ports and addressing server-level security findings.
Understand the exposed environment
Identify where infrastructure, application and payment risks intersected.
Reduce unnecessary exposure
Tighten firewall policy and port access so production services exposed only what operations required.
Correct vulnerability findings
Address security issues surfaced through the incident-response and vulnerability-scanning process.
Confirm the environment again
Repeat scanning and testing after remediation rather than assuming the first change solved the risk.
06 · PCI DSS compliance ownership
The compliance work included both documentation and technical evidence.
I took responsibility for understanding the PCI DSS merchant requirements rather than treating compliance as an external checkbox. That included reading the supporting documentation, understanding the required procedure, completing the Payment Card Industry Data Security Standard Self-Assessment Questionnaire D and preparing the Attestation of Compliance for Merchants.
The technical side of compliance included the Approved Scanning Vendor process. I configured the server IPs that belonged in scope, reviewed scan findings, took the necessary remediation steps and repeated validation work to obtain passing evidence. The project retained the ASV Scan Report Attestation of Scan Compliance and the PCI Executive Report produced through HackerGuardian.
SAQ D
Work through the merchant Self-Assessment Questionnaire against the actual payment and infrastructure environment.
AOC for Merchants
Prepare the formal Attestation of Compliance associated with the merchant PCI self-assessment.
Server IP configuration
Identify and configure the internet-facing server IPs that needed to be included in external vulnerability scanning.
Scan → remediate → pass
Review HackerGuardian findings, correct the underlying issues and re-run scans until the required compliance evidence was achieved.
Merchant assessmentPCI DSS SAQ D
Merchant attestationAttestation of Compliance
ASV evidenceAttestation of Scan Compliance
Technical reportHackerGuardian PCI Executive Report
The sanitized ASV report shows a passing compliance status with 0 identified failing vulnerabilities for the in-scope scan shown.
The supplied final questionnaire page shows the listed PCI DSS requirement categories marked compliant.
07 · Customer-facing storefront payments
Card charging at checkout had to be secure, reliable and correctly reflected in the order state.
The storefront payment workflow was configured around the provider integration, secure credentials and the behavior of the legacy commerce application. The important part was not only transmitting a charge request; the provider result had to map correctly back to the customer order and downstream processing state.
Customer submits order
The storefront prepares the order and payment request.
Gateway integration
Provider API / SDK integration uses configured credentials and secure transport.
Fraud & payment checks
Application and provider-side controls influence whether the transaction can continue.
Order state updated
Authorization outcome is mapped back to the commerce workflow for further processing.
08 · Secured CSR payment backend
Phone-order charging and card refunds were centralized inside one controlled C# application.
Customers who ordered by phone required a secure alternative to the public checkout. I built backend payment functionality in C# so authorized CSRs could charge a customer card for a phone order and process refunds from the same secured environment.
The backend used the payment-provider APIs/SDKs and provider-issued credentials/keys. User authority, transaction actions and provider responses were handled as controlled business operations rather than exposing payment capabilities broadly across the organization.
CSR charges a customer card
Authorized user→C# payment workflow→Gateway→Transaction result
CSR / authorized user refunds a prior transaction
Locate transaction→Validate authority→Refund API→Record result
09 · Transaction risk controls
Security also had to distinguish suspicious behavior from legitimate customers.
The payment environment had experienced suspicious card activity, so fraud controls were configured at both the application and payment-provider levels. I worked directly with the Braintree and CyberSource account settings, fraud configuration and administrative portals rather than limiting the solution to code-level checks.
Transaction context
Evaluate the payment using the risk information available through the payment environment.
Risk decision
Apply configured thresholds or conditions to identify transactions that required different handling.
Protect conversion
Balance stronger fraud controls with the need to allow valid customer purchases to complete.
10 · Payment platform administration
Secure payment systems depend on who can administer them, not only on how they are coded.
I administered the Braintree and CyberSource environments supporting the integrations. That included developer portal configuration, API credentials and keys, user permissions, privileged/admin users and provider-side fraud settings.
This administrative ownership mattered because a technically secure application can still be weakened by poor credential handling, excessive privileges or incorrectly configured gateway controls.
Integration configuration
Maintain provider-side application settings, SDK/API configuration and environment details.
Keys & secure exchange
Handle the credentials and key material required for application-to-gateway communication.
Admin authority & permissions
Control which users had elevated access to the payment-provider environments.
Provider-side controls
Configure fraud/risk settings in the gateway portals in addition to application logic.
11 · Data protection
Reduce unnecessary exposure of sensitive customer information.
The modernization also included stronger handling of customer data. Sensitive information was protected through encryption and payment processing was moved toward provider-managed transaction workflows so the application did not need to treat raw payment data as ordinary business information.
Reduce sensitive-data exposure
Keep payment handling inside appropriate gateway workflows instead of broad application use.
Encrypt customer data
Strengthen protection of sensitive customer information stored or handled by the business systems.
Limit operational access
Security improvements were considered together with server, application and payment-process access.
12 · Testing & production validation
A payment integration is not finished when the API call succeeds.
Both customer-facing and backend payment flows required end-to-end validation. Testing had to cover the provider response, application behavior, transaction result and the downstream business state so a payment could not appear successful in one system while leaving the order in an inconsistent state elsewhere.
Provider configuration
Validate credentials, account setup and gateway-side configuration.
Transaction execution
Test successful and unsuccessful payment paths through the application.
Business-state handling
Confirm the application reacts correctly to gateway outcomes.
Production readiness
Validate the secured environment and payment workflow before relying on it for live commerce.
13 · Engineering decisions
Where payment engineering and infrastructure security had to be treated as the same business problem.
Do not secure checkout on an exposed platform
Server and network controls were part of payment remediation, not a separate infrastructure project.
Storefront and backend transactions have different users
Braintree and CyberSource supported distinct customer-facing and internal operational payment paths.
Compliance evidence should drive remediation
Vulnerability findings were useful only when they produced engineering changes and successful retesting.
Authorization alone is not fraud strategy
Transaction rules were configured to reduce suspicious activity while preserving legitimate checkout.
A gateway response must map correctly to the order
Payment success, failure and application state were validated together in end-to-end testing.
Treat customer and payment data as high-risk assets
Encryption and provider-managed payment workflows reduced avoidable exposure inside business systems.
14 · Technology & platforms
A security and payment stack spanning legacy commerce, cloud infrastructure and specialized providers.
| eCommerce applications | Classic ASP · ASP.NET |
|---|---|
| Backend payment application | C# · phone-order charging · credit-card refunds |
| Website payment gateway | Braintree by PayPal · APIs / SDKs · developer portal administration |
| Backend payment gateway | CyberSource · APIs / SDKs · developer portal administration |
| Credential management | Provider-issued API credentials / keys · secure application configuration |
| Incident / compliance support | SecurityMetrics |
| PCI merchant assessment | PCI DSS Self-Assessment Questionnaire D · Attestation of Compliance for Merchants |
| ASV / PCI scanning | HackerGuardian · ASV Scan Report Attestation of Scan Compliance · PCI Executive Report |
| Infrastructure | HorizonIQ + IONOS dedicated servers · SSL configuration · firewall & port hardening |
| Security controls | Encryption · vulnerability remediation · privileged-user controls · fraud configuration |
| Payment administration | Developer portals · users · permissions · admin authority · fraud settings |
15 · Business impact
Restore confidence in checkout while reducing security and payment risk.
Three payment operations were centralized securely
Storefront charges, CSR phone-order charges and backend refunds were handled through controlled payment workflows.
PCI compliance was owned end to end
SAQ D, Attestation of Compliance, ASV scope, scan remediation and formal HackerGuardian evidence were handled as one program.
Suspicious payment activity was better controlled
Transaction-risk rules gave the payment environment stronger decision controls.
Provider administration became controlled
Developer portals, admin users, permissions, credentials and fraud configuration were managed as part of the security model.
Payment cancellations were reduced
Better gateway configuration and transaction handling helped reduce avoidable payment-related cancellations.
Commerce could operate with stronger safeguards
The business retained working customer and backend payment flows while materially improving the surrounding security posture.
16 · Evidence & compliance artifacts
Real PCI evidence from the production compliance process.
Unlike many implementation projects, this case study has documentary evidence of the administrative and compliance work behind the payment environment. The following screenshots were sanitized before publication and are included only to demonstrate the type of PCI work performed.
01
ASV Scan Report — Attestation of Scan Compliance
01
PASS status
The supplied report visibly records a passing ASV compliance status.
02
0 failing vulnerabilities
The visible scan summary reports no identified failing vulnerabilities for the in-scope component shown.
03
Scope management
The report records the in-scope component count and components confirmed by the scan customer as out of scope.
04
Formal ASV evidence
This is the compliance artifact produced after technical scan configuration, remediation and validation.
02
PCI DSS questionnaire — final compliance page
01
Firewall controls
The questionnaire includes firewall configuration as a formal PCI DSS requirement.
02
Cardholder-data protection
Stored-data protection and encrypted transmission are explicitly represented in the compliance checklist.
03
Access & monitoring
The page covers access restriction, authentication, monitoring and regular security testing.
04
12 requirement areas
The supplied final page shows YES selected for all twelve PCI DSS requirement categories listed.
Privacy & security: company information, contact details, dates and other sensitive values have been removed from the published screenshots. Full PCI reports and questionnaires should remain private.