Case Study Mobile Application Testing

Case Study: Mobile Application Testing — Apple Pay Integration

This case study outlines a ProCheckUp penetration test of a pre-release Apple Pay integration for a large international consumer-facing organisation. The assessment covered the native iOS application, its supporting backend-for-frontend API and the full transaction journey from basket creation through payment authorisation to server-side fulfilment.

Overview

The customer commissioned ProCheckUp to assess a newly integrated Apple Pay checkout flow before production release. Testing examined the payment feature from both an unauthenticated guest-checkout perspective and an authenticated customer perspective.

The engagement combined static binary analysis, dynamic instrumentation and API business-logic testing. Its objective was to determine whether the payment journey remained trustworthy when the mobile client was modified, application methods were hooked and requests were intercepted between the iOS application and the server.

The assessment identified thirteen distinct vulnerabilities. Two were rated Critical because client-controlled state could influence payment-critical processing at separate stages of the transaction lifecycle.

Engagement at a glance

• - Native iOS application and supporting pre-production mobile API
• - Guest-checkout and authenticated-customer testing perspectives
• - Static analysis, runtime instrumentation and intercepted API testing
• - Authorised re-signed IPA for analysis and entitlement-preserving build for payment validation
• - Thirteen final findings, including two Critical business-logic defects
• - Verification retest against a subsequent application build

Assessment boundary: the work focused on the Apple Pay integration and its supporting endpoints rather than full functional testing of the complete mobile application. All payment and request manipulation occurred within the authorised test environment.

Challenge

Mobile payment testing had to separate genuine application defects from expected iOS platform behaviour and from limitations introduced by the security test build.

Platform entitlement versus application defect

Dynamic testing required the supplied IPA to be re-signed after certificate-pinning and jailbreak-detection barriers were removed. Re-signing changed the original Apple Pay merchant-entitlement context, causing the platform payment-availability check to return an unavailable state regardless of the cards provisioned on the test device.

This was a test-distribution constraint rather than evidence of an application vulnerability. ProCheckUp therefore coordinated additional card-provisioning attempts and used a second, entitlement-preserving distribution channel to validate the end-to-end Apple Pay journey under the intended signing context.

Integrity depended on the complete transaction sequence

The highest-impact risks existed between stages: basket calculation, payment-sheet creation, payment authorisation and order fulfilment. Each stage could appear valid when viewed independently while the transaction as a whole allowed price or order state to diverge.

Evidence had to remain repeatable

A planned environment change paused testing, and restricted device screenshot capabilities made proxy history and reproducible request evidence particularly important. Business-logic findings were repeated across multiple order iterations, and conflicting proxy substitution rules were removed before the final severity ratings were confirmed.

Requirements

The engagement included the following technical and operational requirements:

• - Assess the agreed pre-production mobile API from unauthenticated and authenticated perspectives
• - Perform static and dynamic analysis of the supplied iOS application package
• - Align testing to the OWASP Mobile Application Security Testing Guide, OWASP Mobile Top 10 and OWASP API Security Top 10 2023
• - Use MobSF and native binary tooling to review hardening, embedded keys, debug artefacts, symbols and runtime paths
• - Use Frida to enumerate hookable classes and methods and inspect in-memory application context
• - Use an authorised re-signed IPA with certificate pinning and jailbreak detection removed for controlled proxying and instrumentation
• - Use an entitlement-preserving distribution to validate the complete Apple Pay transaction flow
• - Use authorised test payment credentials and customer-provided test accounts
• - Maintain a technical contact for live triage of payment state, build and environment issues
• - Remain within the agreed Apple Pay feature boundary and avoid unrelated application functionality

Solution

ProCheckUp combined Burp Suite proxy interception, MobSF static analysis, native iOS binary tooling and Frida runtime instrumentation. Automated results were treated as discovery inputs; reportable severity depended on manual validation and demonstrated business impact.

The assessment followed four stages:

1. Model: map basket state, API calls, payment-sheet creation, authorisation and fulfilment as one transaction lifecycle.
2. Inspect: analyse the iOS package for embedded key material, symbols, runtime paths, hardening weaknesses and debug-era functionality.
3. Instrument: intercept requests, modify client state and hook relevant classes and methods to challenge runtime trust assumptions.
4. Prove: repeat transaction attempts, remove test-harness conflicts and establish whether modified client input reached the payment framework or server-side commitment.

The final findings were manually correlated to CVSS v3.1 severity ratings and supported with reproducible evidence. The entitlement-preserving build was essential for distinguishing payment-platform behaviour from defects that remained present in the customer’s application and API logic.

Critical Vulnerabilities Identified

The two Critical issues affected separate points in the payment lifecycle. They should not be read as proof that one complete fraud sequence occurred in production; together they demonstrate why price, payment authorisation and fulfilment must be bound to one server-authoritative transaction.

Client-supplied basket price accepted by downstream payment logic — Critical, CVSS 9.1

The application populated local basket state using a value that was not consistently reconciled against the server-authoritative price. During controlled testing, a materially reduced client-side amount reached the Apple Pay payment sheet.

This demonstrated that an unauthenticated user able to modify mobile traffic could influence payment-critical state before authorisation. The trusted payment framework accurately displayed the value it was given; the defect was that the application did not reliably establish the authoritative amount before creating the payment request.

Recommendation: calculate price, discounts, tax and fees server-side immediately before payment creation; bind the result to an immutable basket or order identifier; and reject any client value that differs from the server record.

Post-authorisation fulfilment body accepted without sufficient validation — Critical, CVSS 9.1

A distinct integrity gap existed after a legitimate Apple Pay authorisation but before the server committed the order record. The fulfilment request remained modifiable, allowing controlled testing to create a mismatch between the authorised payment context and the order state written by the backend.

This created potential reconciliation, fraud, customer-impact and operational risks because payment, order and fulfilment records could cease to represent the same transaction.

Recommendation: derive fulfilment values from the server-side authorised transaction, cryptographically or logically bind the payment token to the immutable order record, enforce idempotency and reject fields that do not match the authorised amount and basket.

Additional Findings

Embedded third-party key material — Medium, CVSS 6.5

Static analysis identified third-party API and telemetry keys within the distributed package. Mobile binaries should be assumed recoverable by an attacker, so each exposed value required review for service restrictions, permissions, environment separation and rotation.

Binary hardening and debug artefacts — Medium, CVSS 5.5

The supplied application artefact retained residual exported symbols and runtime search-path information, lowering the effort required to understand payment-critical code. The assessment showed that project build settings must be verified against the resulting IPA rather than accepted solely from configuration declarations.

Runtime token and payment-session exposure — Medium, CVSS 5.3

Initial instrumentation identified hookable authentication-token and payment-processing context. This specific result was not reproduced during the verification retest under corrected test conditions, so the final status should remain distinct from findings that were conclusively reproduced.

Hookable backend URL override methods — Medium, CVSS 4.3

Debug-era methods capable of changing backend base URLs remained present and invocable in the application process. In an instrumented environment, these methods could redirect application traffic towards an attacker-controlled endpoint.

Lower-severity assurance themes

The remaining findings covered payment-method and identity-enumeration behaviour, exposed API documentation, telemetry and data-governance considerations, and insufficient rate limiting on payment-adjacent endpoints. These issues broadened the abuse-case and governance view without being presented as equivalent to the two Critical transaction-integrity defects.

Payment-Integrity Attack Model

The two Critical findings occurred at different points in the transaction. The following authorised risk model shows how client-controlled state could cause records to diverge if server-side controls did not bind the stages together:

• 1. Basket created: a guest or authenticated customer begins checkout.
• 2. Client value modified: local basket or request state is altered before downstream payment processing.
• 3. Payment total formed: the modified value reaches the payment-sheet request.
• 4. Payment authorised: Apple Pay produces a legitimate authorisation for the amount presented by the application.
• 5. Fulfilment intercepted: the post-authorisation request remains mutable between the client and server.
• 6. Server accepts divergent state: order attributes no longer match the authorised payment context.
• 7. Records disagree: payment, order and fulfilment systems cease to share one authoritative transaction truth.

The model illustrates combined integrity risk. It does not claim that every step was executed as one end-to-end fraud scenario outside the controlled assessment.

Verification Retest

ProCheckUp retested a subsequent build to determine whether engineering changes were present in the delivered artefact and whether earlier observations remained reproducible.

• - The residual runtime search-path sub-finding was confirmed as resolved
• - Runtime extraction of the OIDC token context was not reproduced under corrected retest conditions
• - Debug symbol stripping remained incomplete at the binary level
• - Backend URL override methods remained present and callable
• - The entitlement-preserving build confirmed that the earlier Apple Pay availability issue belonged to the re-signing context rather than the application
• - The two Critical transaction-integrity findings remained within a formal engineering and risk-treatment programme

Important status boundary: risk acceptance is a governance decision, not technical remediation. Publication should not describe the Critical issues as closed unless a later independent retest confirms that the underlying transaction logic has been corrected.

Outcome

The engagement gave the customer a defensible view of release risk across the mobile binary, runtime, API and payment lifecycle. It demonstrated that Apple Pay’s platform protections could not compensate for application logic that accepted mutable client state at payment-critical boundaries.

The assessment also prevented a platform constraint from being misreported as a product defect. By combining an analysis-ready IPA with an entitlement-preserving build and live engineering triage, ProCheckUp established which symptoms were caused by re-signing and which represented genuine weaknesses in application or backend behaviour.

The verification retest confirmed one binary-hardening improvement, removed one runtime finding from the reproduced set and showed that other build-level issues remained open. The Critical business-logic findings continued through a formal remediation and risk-treatment process.

Important publication boundary: the source narrative supports the assessment and partial retest status. It does not establish that all findings were remediated, that the Critical issues were independently closed or that the payment feature entered production.

Remediation Priorities

Immediate payment-integrity controls

• - Recalculate all payment values on the server immediately before payment creation
• - Bind payment authorisation to one immutable server-side basket or order identifier
• - Reject fulfilment fields that do not match the authorised transaction
• - Treat Critical payment-integrity defects as release gates unless formally governed
• - Review and restrict all third-party keys embedded within the application

Engineering hardening

• - Remove or compile out backend URL override methods from production builds
• - Verify symbol stripping, encryption and runtime paths against the final distributed IPA
• - Minimise sensitive token lifetime and unnecessary exposure in process memory
• - Use allowlisted configuration and controlled environment selection
• - Add server-side idempotency, reconciliation and explicit transaction-state validation
• - Apply effective rate limiting and abuse monitoring to payment-adjacent endpoints

Ongoing assurance

• - Automate negative tests for price, basket and fulfilment manipulation
• - Test both guest and authenticated payment journeys after material changes
• - Monitor differences between authorised amount, captured amount and order value
• - Maintain an entitlement-preserving security-test distribution route
• - Retest open and accepted risks after remediation or architecture change

The Core Security Lesson

Payment UI integrity is not transaction integrity.

A trusted platform can securely authorise exactly what the application asks it to authorise. The application and server must still prove that price, payment, order and fulfilment all refer to the same immutable, server-authoritative transaction.

The correct question is not simply:

“Did the Apple Pay sheet display correctly?”

It is:

“Can the server prove that the amount authorised is the amount priced, committed and fulfilled?”

How ProCheckUp Helps

ProCheckUp’s mobile application testing services assess the complete security boundary around native applications, supporting APIs, runtime controls and release processes. Support can include:

• - iOS and Android static and dynamic application testing
• - Mobile API and backend-for-frontend penetration testing
• - Payment and checkout business-logic assessment
• - Certificate-pinning and jailbreak or root-control evaluation
• - Runtime instrumentation and reverse engineering
• - Binary hardening and embedded-secret review
• - Guest and authenticated workflow testing
• - OWASP MASTG and mobile abuse-case mapping
• - Verification retesting and release-gate assurance
• - PCI DSS consultancy for payment-data scope and control evidence

Related services include mobile application testing, application penetration testing and PCI DSS QSA consultancy.

Conclusion

This engagement demonstrated why mobile payment assurance must extend beyond the visible payment sheet. Static review, runtime instrumentation, API manipulation and entitlement-preserving transaction testing each answered a different part of the security question.

By making the server authoritative, binding payment and fulfilment to one immutable record, removing avoidable runtime leverage and regression-testing negative payment paths, organisations can substantially reduce fraud and reconciliation risk before release.

To discuss an iOS or Android application penetration test, payment integration assessment or mobile release-security review, contact ProCheckUp.