Category: Web

Web development is the work involved in developing a website for the Internet (World Wide Web) or an intranet (a private network).[1] Web development can range from developing a simple single static page of plain text to complex web applications, electronic businesses, and social network services. A more comprehensive list of tasks to which Web development commonly refers, may include Web engineering, Web design, Web content development, client liaison, client-side/server-side scripting, Web server and network security configuration, and e-commerce development.

  • App Store Server Notifications V2 in Laravel (Step-by-Step Guide + PHP JWT Example)

    App Store Server Notifications V2 in Laravel (Step-by-Step Guide + PHP JWT Example)

    App Store Server Notifications

    App Store Server Notifications V2 allows Apple to notify your backend in real time about subscription events such as renewals, cancellations, refunds, and billing issues. In this guide, you’ll learn how to decode, verify, and process App Store Server Notifications V2 using PHP and Laravel, with practical examples and best practices for production use.

    App offering subscription based products must use App Store Server Notification to verify the purchase, renew the subscription, cancel the subscription, and more.

    What are App Store Server Notifications?

    App Store Server Notifications are webhooks sent by Apple to your server whenever a significant event happens to an in-app purchase or auto-renewable subscription.

    Common events include:

    • Subscription renewal
    • Cancellation or expiration
    • Refunds and revocations
    • Billing retry failures
    • Price increases

    With Server Notifications V2, Apple sends a signed payload (JWT) that contains detailed transaction and renewal information, allowing your backend to stay in sync without relying solely on client-side validation.

    Why Use Version 2 (vs V1)?

    Apple introduced Server Notifications V2 to replace V1 with a more secure, structured, and extensible format.

    Key advantages of V2:

    • Uses JWT (JSON Web Tokens) for payload security
    • Provides richer transaction and renewal data
    • Supports App Store Server API integration
    • Better future compatibility with Apple’s subscription system

    If you’re building or maintaining a modern subscription-based app, V2 is the recommended and future-proof choice.

    How Apple Server Notifications Work
    The notification flow looks like this:

    1. A subscription event occurs on the App Store
    2. Apple sends a POST request to your webhook endpoint
    3. The request contains a signedPayload
    4. Your server:
      • Decodes the JWT
      • Verifies the signature
      • Extracts transaction and renewal data
    5. Your backend updates the user subscription status accordingly

    This process ensures your server remains the source of truth for subscription state.

    My Intentions

    My main goal is to retrieve the originalTransactionId from the notification data. Then, when a subscription expires or Is Refunded, it will downgrade the user’s subscription status.

    Related reading

    Step-by-Step Implementation (without library)

    If you prefer full control, you can implement Server Notifications V2 without any third-party libraries.

    High-level steps:

    1. Read the raw POST body from Apple
    2. Extract the signedPayload
    3. Split the JWT into header, payload, and signature
    4. Base64-decode the payload
    5. Parse and process the JSON data

    This approach is useful for:

    • Learning how V2 works internally
    • Minimal dependencies
    • Custom verification logic

    However, you must be careful with signature verification and edge cases.

    Implementation with JWT Library

    Using a JWT library simplifies decoding and validation while reducing security risks.

    Typical steps:

    1. Install a trusted JWT library
    2. Decode the signedPayload
    3. Validate the JWT signature using Apple’s public key
    4. Extract:
      • notificationType
      • subtype
      • transactionInfo
      • renewalInfo

    This method is recommended for most production systems because it is safer, cleaner, and easier to maintain.

    App Store Configuration

    User purchases we verify Apple’s receipt and we save originalTransactionId in our database. So each user has originalTransactionId and we can find the user with this originalTransactionId. You can read more about this here Auto-renewable subscriptions with SwiftUI

    Make sure you set your app store notification URL on the AppStoreConnect. Choose Version 2 Notifications.

    App Store Server Notifications  V2 with JWT, PHP and Laravel

    Each data will look like this, call it signedPayload.

    App Store Server Notifications  V2 with JWT, PHP and Laravel

    The signedPayload object is a JWS representation. To get the transaction and subscription renewal details from the notification payload, process the signedPayload as follows:

    1. Parse signedPayload to identify the JWS header, payload, and signature representations.
    2. Base64 URL-decode the payload to get the responseBodyV2DecodedPayload. The decoded payload contains the notificationType , subtype, other notification metadata, and a data object.
    3. The data object contains a signedTransactionInfo (JWSTransaction) and depending on the notification type, a signedRenewalInfo (JWSRenewalInfo). Parse and Base64 URL-decode these signed JWS representations to get transaction and subscription renewal details.

    Each of the signed JWS representations, signedPayloadsignedTransactionInfo, and signedRenewalInfo, have a JWS signature that you can validate on your server. Use the algorithm specified in the header’s alg parameter to validate the signature. For more information about validating signatures, see the JSON Web Signature (JWS) IETF RFC 7515 specification.

    Hopefully, you are already getting this data. Now let’s get originalTransactionId from this. We will do this without any 3rd party library first to understand the process.

    First thing, I will download the Apple root certificate and make it.PEM file from it.

    Download the certificate https://www.apple.com/certificateauthority/AppleRootCA-G3.cer

    Get .PEM file from it, on your Mac Terminal

    openssl x509 -in AppleRootCA-G3.cer -out apple_root.pem

    For testing purposes, I’m loading apple_root.pem and my signedPayload from a file called notification.json (replace it with file_get_contents(‘php://input’);) and then decoding the signedPayload. signedPayload has three parts, separated by .(dot), line 13.

    The first part is the header, the Second part is the body (payload), and the Third part is the signature. The header has an algorithm and x5c, x5c has three elements. Certificate, intermediate certificate, and root certificate. We can verify the certificate in two steps. Once the verification is completed, we know we have signedPayload from Apple.

    Finally, decode the payload again and get the originalTransactionId from lines 56 to 65.

    Server Side

    For this article, our production server URL looks like inafiz.com/jwt.php. You can get whatever Apple sends you and write a log in your server if you are interested.

    $appleData = file_get_contents('php://input');
    $file = fopen(
        "/var/www/html/appstore_prod.log", "a"
    );
    fwrite($file, $appleData);
    fclose($file);
    

    Without any 3rd party library(not recommended).

    <?php
    
    ini_set('display_errors', 1);
    error_reporting(E_ALL);
    
    // Download the certificate -> https://www.apple.com/certificateauthority/AppleRootCA-G3.cer
    // Convert it to .PEM file, run on macOS terminal ->  ```bash openssl x509 -in AppleRootCA-G3.cer -out apple_root.pem```
    
    $pem = file_get_contents('apple_root.pem');
    $data = file_get_contents('notification.json'); // replace with file_get_contents('php://input');
    $json = json_decode($data);
    
    $header_payload_secret = explode('.', $json->signedPayload);
    
    //------------------------------------------
    // Header
    //------------------------------------------
    $header = json_decode(base64_decode($header_payload_secret[0]));
    $algorithm = $header->alg;
    $x5c = $header->x5c; // array
    $certificate = $x5c[0];
    $intermediate_certificate = $x5c[1];
    $root_certificate = $x5c[2];
    
    $certificate =
          "-----BEGIN CERTIFICATE-----\n"
        . $certificate
        . "\n-----END CERTIFICATE-----";
    
    $intermediate_certificate =
          "-----BEGIN CERTIFICATE-----\n"
        . $intermediate_certificate
        . "\n-----END CERTIFICATE-----";
    
    $root_certificate =
          "-----BEGIN CERTIFICATE-----\n"
        . $root_certificate
        . "\n-----END CERTIFICATE-----";
    
    //------------------------------------------
    // Verify the notification request   
    //------------------------------------------
    if (openssl_x509_verify($intermediate_certificate, $root_certificate) != 1){ 
        echo 'Intermediate and Root certificate do not match';
        exit;
    }
    
    // Verify again with Apple root certificate
    if (openssl_x509_verify($root_certificate, $pem) == 1){
        //------------------------------------------
        // Payload
        //------------------------------------------
        // https://developer.apple.com/documentation/appstoreservernotifications/notificationtype
        // https://developer.apple.com/documentation/appstoreservernotifications/subtype
        $payload = json_decode(base64_decode($header_payload_secret[1]));
        $notificationType = $payload->notificationType;
        $subtype = $payload->subtype;
    
        if ($notificationType == "EXPIRED" || $notificationType == "REFUND") {
            $transactionInfo = $payload->data->signedTransactionInfo;
            $ti = explode('.', $transactionInfo);
            
            $data = json_decode(base64_decode($ti[1]));
            var_dump($data); // this will contain our originalTransactionId
        }
    } else {
        echo 'Header is not valid';
        exit;
    }

    Using firebase/php-jwt in composer (recommended), big difference is to use the public key to decode the payload using JWT.

    composer require firebase/php-jwt
    <?php
    
    ini_set('display_errors', 1);
    error_reporting(E_ALL);
    
    // No need these 3 lines for Laravel
    require_once './vendor/firebase/php-jwt/src/JWT.php';
    require_once './vendor/firebase/php-jwt/src/JWK.php';
    require_once './vendor/firebase/php-jwt/src/Key.php';
    
    use Firebase\JWT\JWT;
    use Firebase\JWT\Key;
    
    // Download the certificate -> https://www.apple.com/certificateauthority/AppleRootCA-G3.cer
    // Convert it to .PEM file, run on macOS terminal ->  ```bash openssl x509 -in AppleRootCA-G3.cer -out apple_root.pem```
    
    $pem = file_get_contents('apple_root.pem');
    
    $data = file_get_contents('notification.json');  // replace with file_get_contents('php://input');
    $json = json_decode($data);
    
    $header_payload_secret = explode('.', $json->signedPayload);
    
    //------------------------------------------
    // Header
    //------------------------------------------
    $header = json_decode(base64_decode($header_payload_secret[0]));
    $algorithm = $header->alg;
    $x5c = $header->x5c; // array
    $certificate = $x5c[0];
    $intermediate_certificate = $x5c[1];
    $root_certificate = $x5c[2];
    
    $certificate =
          "-----BEGIN CERTIFICATE-----\n"
        . $certificate
        . "\n-----END CERTIFICATE-----";
    
    $intermediate_certificate =
          "-----BEGIN CERTIFICATE-----\n"
        . $intermediate_certificate
        . "\n-----END CERTIFICATE-----";
    
    $root_certificate =
          "-----BEGIN CERTIFICATE-----\n"
        . $root_certificate
        . "\n-----END CERTIFICATE-----";
    
    //------------------------------------------
    // Verify the notification request   
    //------------------------------------------
    
    if (openssl_x509_verify($intermediate_certificate, $root_certificate) != 1){ 
        echo 'Intermediate and Root certificate do not match';
        exit;
    }
    
    // Verify again with Apple root certificate
    if (openssl_x509_verify($root_certificate, $pem) == 1){
        $cert_object = openssl_x509_read($certificate);
        $pkey_object = openssl_pkey_get_public($cert_object);
        $pkey_array = openssl_pkey_get_details($pkey_object);
        $publicKey = $pkey_array['key'];
    
        //------------------------------------------
        // Payload
        //------------------------------------------
        $payload = json_decode(base64_decode($header_payload_secret[1]));
        $notificationType = $payload->notificationType;
    
        //if ($notificationType == "EXPIRED" || $notificationType == "REFUND") {
            $transactionInfo = $payload->data->signedTransactionInfo;
            $signedRenewalInfo = $payload->data->signedRenewalInfo;
    
            $transactionDecodedData = JWT::decode($transactionInfo, new Key($publicKey, $algorithm));
            var_dump($transactionDecodedData->originalTransactionId);
            echo "========================================";
            $signedRenewalDecodedData = JWT::decode($signedRenewalInfo, new Key($publicKey, $algorithm));
            var_dump($signedRenewalDecodedData);
        //}
    
    } else {
        echo 'Header is not valid';
        exit;
    }

    Conclusion & Next Steps

    App Store Server Notifications V2 are essential for managing subscriptions reliably in modern iOS apps.

    By implementing them correctly in PHP and Laravel, you can:

    • Keep subscription states accurate
    • React to real-time billing events
    • Reduce reliance on client-side receipt validation

    Next steps:

    • Add App Store Server API integration
    • Store originalTransactionId as a primary key
    • Build retry-safe webhook processing
    • Automate subscription audits

    If you’d like a full Laravel package or production-ready webhook example, feel free to reach out or leave a comment

    Download the source code

    Spread the love
  • Java Factory Design Pattern

    Java Factory Design Pattern

    Java Factory Design Pattern

    The factory design pattern is a common design pattern used in software development, particularly in object-oriented programming languages like Java. The factory design pattern is a creational design pattern, which means that it deals with object creation.

    The factory design pattern is a way to provide a common interface for creating objects without specifying the exact class of object that will be created. This allows the code that uses the objects to be independent of the specific implementation of the objects.

    Here is an example of how the factory design pattern might be implemented in Java:

    public interface Shape {
      void draw();
    }
    
    public class Circle implements Shape {
      @Override
      public void draw() {
        // code to draw a circle
      }
    }
    
    public class Rectangle implements Shape {
      @Override
      public void draw() {
        // code to draw a rectangle
      }
    }
    
    public class ShapeFactory {
      public static Shape getShape(String shapeType) {
        if (shapeType == null) {
          return null;
        }
        if (shapeType.equalsIgnoreCase("CIRCLE")) {
          return new Circle();
        } else if (shapeType.equalsIgnoreCase("RECTANGLE")) {
          return new Rectangle();
        }
        return null;
      }
    }
    

    In the example above, the ShapeFactory class provides a static method called getShape() that takes a shapeType as an input and returns an object of the specified Shape type. This allows the code that uses the ShapeFactory to create Shape objects without knowing the exact implementation of the objects.

    The factory design pattern is a useful pattern to use in Java because it promotes loose coupling and code reuse. It allows you to create objects without specifying their exact class, which makes your code more flexible and easier to maintain.

    Spread the love
  • Laravel Sanctum Tutorial Step by Step

    Laravel Sanctum Tutorial Step by Step

    Laravel Sanctum provides a featherweight authentication system for single-page applications, mobile applications, and simple, token-based APIs. Sanctum allows each user of your application to generate multiple API tokens for their account. These tokens may be granted abilities/scopes which specify which actions the tokens are allowed to perform.

    Installation

    composer require laravel/sanctum and composer update

    Next, you should publish the Sanctum configuration and migration files using the vendor:publish Artisan command. 

    php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"
    php artisan migrate 

    You can also use following sql for creating table, if there is a problem to run migrate command.

    CREATE TABLE `personal_access_tokens` (
       `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
       `tokenable_type` varchar(255) NOT NULL,
       `tokenable_id` bigint(20) unsigned NOT NULL,
       `name` varchar(255) NOT NULL,
       `token` varchar(64) NOT NULL,
       `abilities` text DEFAULT NULL,
       `last_used_at` timestamp NULL DEFAULT NULL,
       `created_at` timestamp NULL DEFAULT NULL,
       `updated_at` timestamp NULL DEFAULT NULL,
       PRIMARY KEY (`id`),
       UNIQUE KEY `personal_access_tokens_token_unique` (`token`),
       KEY `personal_access_tokens_tokenable_type_tokenable_id_index` (`tokenable_type`,`tokenable_id`)
     ) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8

    Next, if you plan to utilize Sanctum to authenticate an SPA, you should add Sanctum’s middleware to your api middleware group within your application’s app/Http/Kernel.php file:

    'api' => [
                'throttle:60,1',
                'bindings',
                \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
            ],
    Laravel Sanctum Tutorial Step by Step

    Download source code

    Spread the love