Key Takeaways

• Decoding Recurring Payments: Recurring payments come in various flavors – fixed, variable, and on-demand – each catering to different user needs and business models.
• The Two Sides of the Coin: Recurring payments offer a win-win situation. Businesses enjoy streamlined operations, predictable revenue, and simplified customer management. Customers get uninterrupted service. However, successful implementation requires robust security measures and compliance with data protection regulations.
• Staying Compliant: Businesses must comply with international and local regulations to ensure data privacy and fair billing practices. This builds trust with customers and avoids legal issues.
• Choosing a Provider: When selecting a recurring payment provider, prioritize seamless integration, robust security, responsive customer support, and scalability for future growth.
• Top Payment Providers: Companies like Stripe, PayPal, Square, and Adyen offer diverse functionalities that cater to different business needs. Choosing a provider that aligns with your specific requirements is crucial.

‍

What Are Recurring Payments?

Recurring payments, also called subscriptions or automated payments, are automated transactions that automatically charge the chosen payment method (credit card, bank account, or digital wallet) at predetermined intervals, typically monthly, annually, or quarterly. This ensures consumers receive uninterrupted access to the subscription services. In essence, recurring payments streamline the process for both consumers and the business, ensuring a smooth and hassle-free experience.

Types of Recurring Payments

Recurring payments come in a variety of flavors, offering flexibility for both consumers and businesses. 

Fixed Recurring Payments

Fixed recurring payments charge a consistent amount at set intervals – think monthly gym memberships or annual software licenses. This predictability makes budgeting easy for subscribers, while businesses enjoy steady revenue streams.

Variable Recurring Payments

Variable recurring payments fluctuate based on usage, as seen with utility bills or phone charges. While this can require more attention from subscribers for budgeting, it allows businesses to accurately reflect service consumption in their pricing.

On-Demand Subscriptions

Putting the power in the user's hands, on-demand subscriptions allow for ultimate flexibility. Think of streaming services where users choose what and when to watch. Subscribers can control their spending, and businesses benefit from a wider customer base.

‍

Understanding these types provides valuable insight into how various subscription models influence consumer behavior and business revenue streams. Each type caters to different needs, giving individuals and businesses flexibility in managing their finances and subscriptions.

‍

Benefits of Recurring Payments

For Businesses

Streamlining the billing process, recurring payments ensures consistent revenue streams, making financial planning and budget management easy for businesses. Automating transactions reduces administrative overhead, minimizes errors, and frees up resources for other areas. Recurring payments also enable a more positive customer relationship by offering a convenient payment experience, which can lead to higher retention rates. Additionally, valuable insights gleaned from payment analytics give businesses a chance to tailor their services effectively and boost customer satisfaction.

For Consumers

Recurring payments eliminate the need for consumers to remember due dates or perform manual transactions, freeing them from the stress of missed payments and late fees. Recurring payments also empower them to take control of their budget.  With predictable expenses, they can easily plan their finances in advance.  Additionally, subscribing to services can often lead to cost savings. Businesses may offer discounts and bundled pricing options to incentivize long-term commitments.  These advantages, combined with the ability to access a wide array of services tailored to consumer’s specific interests, make recurring payments an attractive option for anyone looking to simplify their financial life.

‍

Challenges of Implementing Recurring Payments

Technical Challenges

If you plan to integrate recurring payments as a part of your payment system, here are some technical hurdles to consider.

• Integration Challenges: Integrating with various payment gateways and processors requires robust APIs that ensure compatibility across platforms. This integration needs extensive attention to data synchronization and real-time processing to prevent delays and errors in payments.
• Ironclad Security: Security is paramount. Sensitive customer data, including credit card information, requires strong encryption and compliance with security standards like PCI DSS. A data breach can lead to financial losses and erode customer trust.
• Scaling Up for Success: Scalability is crucial. As the volume of customers increases, the system must have the capacity to handle larger data volumes and more transactions without compromising performance. This necessitates scalable solutions that can grow with the business needs without incurring downtime or degraded service quality.

‍

Regulatory and Compliance Issues

Staying compliant with international, federal, and state regulations can be a complex task, especially for businesses that operate globally. For instance, data privacy regulations like the European Union's GDPR and the US's CCPA dictate how businesses can store and process customer information, impacting subscription management practices.  

Businesses must ensure transparent billing practices and disclose all terms and conditions clearly to avoid violating consumer protection laws, which could result in hefty fines and legal challenges. Adherence to financial standards like PCI DSS for payment security is not just mandatory but critical for maintaining consumer trust. A data breach can have far-reaching consequences, so robust security measures are essential.

Navigating these technical and regulatory landscapes requires dedicated effort from businesses to not only implement but continuously update and audit their recurring payment systems to comply with current laws and technological advancements.

‍

Choosing the Right Recurring Payment Provider

Choosing the right recurring payment provider is crucial for delivering a smooth subscription experience to consumers. Here are some key features to consider:

• Seamless Integration: Look for a provider that offers APIs and plugins that integrate easily with your existing business systems, like e-commerce platforms and accounting software. This will save you time and resources during setup.
• Robust Security: Security is paramount. Choose a provider that offers strong encryption features, adheres to PCI DSS standards, and implements fraud detection and prevention measures to safeguard customer data and prevent unauthorized transactions.
• Reliable Support: When technical glitches arise, dependable customer support is essential. Opt for providers offering 24/7 support through multiple channels like phone, email, and chat for timely resolution of any issues.
• Scalability for Growth: Consider a provider that can scale with your business, offering support for a variety of payment methods and currencies, especially if you plan on operating internationally.
• Cost Considerations: Don't forget about the bottom line. Pricing structures and transaction fees can vary between providers. Factor in these costs when making your decision.

‍

Top Providers in the Market

While this is not an exhaustive list, several top players in the market cater to businesses for recurring payments:

• Stripe: Known for its powerful API and extensive suite of tools, Stripe facilitates a wide array of payment options, including credit cards and mobile payments. It's designed to be easy to use and is favored by tech-savvy businesses.
• PayPal: A globally recognized brand, PayPal offers extensive coverage when it comes to currencies and is perceived as a secure option by consumers. It's particularly effective for businesses looking for a provider with a large existing user base.
• Square: Ideal for small to medium-sized businesses, Square offers a straightforward fee structure and is known for its user-friendly interface. It also provides solutions for both online and offline transactions.
• Adyen: Adyen provides a single platform for accepting payments anywhere in the world with direct access to a broad spectrum of payment methods. It's well-suited for large enterprises looking for a global reach.

Selecting the right provider involves understanding your business's specific needs and matching them with the features and services offered by these providers. Remember, the best choice often balances cost, user experience, and comprehensive functionality.

‍

Conclusion

From offering businesses predictable revenue streams to simplifying budgeting for consumers, the benefits of recurring payments are undeniable.  However, navigating the available options and ensuring compliance requires a well-informed approach.  By carefully considering a payment provider's features against your specific needs, you can ensure a smooth and secure experience for both you and your customers.  With the right recurring payment solution in place, you can move forward with confidence, empowered to achieve your business objectives and growth plans. Discover how NamiML's intelligent platform can streamline your subscription billing and boost revenue predictability—try NamiML today and transform your subscription experience.

‍

Frequently Asked Questions

What are the benefits of recurring payments for businesses?

Recurring payments streamline business operations by automating billing and payment processing, freeing up your staff to focus on other crucial tasks. This reduces administrative overhead and minimizes errors associated with manual billing. Recurring payments ensure a steady stream of revenue, making financial planning and budgeting a breeze, so you ou can confidently forecast future income and make informed business decisions. Recurring payments offer a seamless experience for your customers, eliminating the hassle of missed payments and late fees. This translates into positive customer relationships and can lead to higher retention rates. Recurring payments also generate valuable data on customer spending habits. You can leverage this data to tailor your services, optimize pricing strategies, and ultimately boost customer satisfaction.

‍

What challenges come with implementing recurring payment systems?

Implementing recurring payments can involve technical hurdles like integrating the system with your existing setup. Security is also a major concern, as robust measures are needed to protect sensitive customer data and not doing so can attract hefty fines and legal challenges. Additionally, adhering to the constantly changing landscape of regulations, at local and international levels, can be challenging for businesses.

‍

How do you choose the right recurring payment provider?

Choosing the right recurring payment partner requires careful evaluation. A smooth integration with your existing business systems, like accounting software or your e-commerce platform, is crucial to save time and resources during setup. Protecting customer data is paramount. Choose a provider with robust security measures like encryption and compliance with PCI DSS standards to ensure customer trust. Reliable customer support is essential. Look for a provider that offers 24/7 support through multiple channels to ensure prompt assistance with any issues. Also, consider your future growth plans and choose a provider that can scale with your business needs. Factor in transaction fees and monthly costs when making your decision to find a solution that fits your budget.

‍

Who are some top recurring payment providers?

Notable providers in the market include Stripe, PayPal, Square, and Adyen. Each offers distinct strengths and is targeted toward varying business sizes and types. Evaluating their specific features and alignment with your business goals is essential when choosing a provider.

‍

Why is it important to align a provider’s features with business needs?

Choosing a recurring payment provider with features that match your specific needs is crucial for several reasons. By aligning features with your needs, you avoid unnecessary costs and ensure you're getting the most value for your money. A smooth experience for both you and your customers is essential.  Features that match your needs, like easy integration or 24/7 support, contribute to a more streamlined process. Choosing a provider with the functionalities you require, like scalability or support for multiple currencies, ensures your recurring payment system operates efficiently.

‍

Subscription and Paywall Engagement Gets Personal with Hyper-Personalized Purchasing Experiences

DENVER, 5 June 2024 –Nami® ML today launched a groundbreaking new version of their Subscription Studio platform, empowering businesses to take their revenue from a trickle to a tidal wave.

While subscription services swelled over the past decade, the individualized experience that today’s consumers demand has been arduous to come by, primarily because producing any purchasing experience takes a lot of time and resources - it can take hundreds of hours to design, develop, deploy, test, and refine a single paywall, and those hours skyrocket when a subscription is offered at-scale across a variety of platforms and ecosystems.

A Thousand Paywalls

With Nami’s updated Paywall Creator, companies can adjust pricing, alter positioning or launch a new design in minutes– everywhere they sell. If a company can create one paywall in ten minutes, then they can create a thousand paywalls in about the amount of time it previously took to create a single paywall.

With the power of a thousand paywalls, a company can run countless A/B tests and granularly target users to give every customer a personalized purchasing experience.

“The best way to grow subscription revenue is to get personal. Nami customers rapidly discover what resonates, which translates to more revenue. Nami pays for itself after a few tests, ” explains Dan Burcaw, Co-Founder, CEO of Nami ML.

Harmonizing the Subscriber Journey

Nami’s updated platform makes it easy to discover what each customer wants, then deliver a level of personalization never before achieved at scale. Paywalls can be contextualized at different moments - as your trial expires or when trying to access premium content, for example - or target CRM audience segments or even individual users.

Today’s release transforms how companies approach subscriptions. No longer is a paywall a mere product selection point - it is a marketing asset.

Burcaw continues, “The purchase experience is now in harmony with other marketing channels for a truly orchestrated subscriber journey. The result is accelerating revenue from a wave of loyal customers.”

About Nami ML

Nami ML helps brands deploy personalized purchasing experiences that foster long-lasting loyalty and drive revenue. Visit https://namiml.com and request a demo from a product expert today.

Nami is a registered trademark of Nami ML Inc.

Update: Since this guide was published, Apple announced StoreKit 2 which adds new capabilities and APIs such as Signed Transactions. StoreKit 1-style receipts and APIs will continue to be available, so we hope this article will continue to be a useful reference. If you're interested in learning more about StoreKit 2, head over here. Also, the new APIs are a major change and another and a great time to build atop Nami which abstracts away these underlying implementation details.
‍

What's an App Store Receipt?

An App Store receipt is a digital proof of purchase generated by Apple for any transaction made within the App Store, including app purchases, in-app purchases, and subscriptions. This receipt is a critical component in ensuring the integrity and authenticity of transactions, as it contains detailed information about the purchase, such as the product ID, transaction ID, purchase date, and subscription details if applicable.

The receipt is stored on the user's device and can be retrieved and verified to confirm that the user has made a legitimate purchase. This verification process typically involves sending the receipt data to Apple's servers, where it is checked for validity and authenticity. By verifying receipts, app developers can protect their apps from fraudulent transactions and unauthorized access to premium content or features.

The receipt data provided by StoreKit is a Base64-encoded. To receive a decoded version, described in detail in this article, you need to transmit the encoded receipt to Apple’s verifyReceipt endpoint. To fully understand verifyReceipt, see this article where we code a simple Python script step-by-step that demonstrates how to send an encoded receipt and receive the decoded receipt.

Why Does it Need to be Verified?

Why is all of this necessary? The two most important reasons:

1. Receipt validation helps you ensure a user is getting access to what they purchased — which is especially important with subscriptions
2. Validating receipts from a server-side provides an important safeguard against piracy

The mechanics of receipt validation are relatively straightforward as demonstrated in the Python script referenced early.

However, grokking the decoded receipt itself is painful. It’s not the most elegant data structure in the world, and there are all sorts of esoteric details and nuances. Our goal with this article is build upon and go beyond Apple’s documentation to help you better understand the decoded receipt and avoid common (and more exotic) pitfalls.

How To Validate Receipts in App Store

1. Obtain the Receipt Data

The first step is to obtain the receipt data from the app. This data can be retrieved using the SKReceiptRefreshRequest class or from the receipt URL located in the app’s bundle.
‍

if let appStoreReceiptURL = Bundle.main.appStoreReceiptURL,
  FileManager.default.fileExists(atPath: appStoreReceiptURL.path) {
   do {
       let receiptData = try Data(contentsOf: appStoreReceiptURL, options: .alwaysMapped)
       let receiptString = receiptData.base64EncodedString(options: [])
       // Send receiptString to your server for verification
   } catch {
       print("Couldn't read receipt data with error: " + error.localizedDescription)
   }
}

‍

‍


2. Send Receipt Data to Your Server

Once you have the receipt data, you need to send it to your server. This step is crucial because the verification process should be performed on a secure server to prevent tampering. Your server will then forward the receipt data to Apple's verification server.

‍

3. Verify Receipt with Apple

Your server should send a request to Apple’s verification server at the following URL:

• For production: https://buy.itunes.apple.com/verifyReceipt
• For sandbox: https://sandbox.itunes.apple.com/verifyReceipt

The request should include the receipt data and your app’s shared secret for subscriptions. Here's an example using Swift's URLSession to send the receipt data:

‍

‍

4. Handle the Response

Apple’s response will include the status of the receipt and, if valid, the receipt’s details. Your server should parse this response and take appropriate action, such as granting the purchased content or renewing a subscription.

‍

‍

let requestDictionary: [String: Any] = ["receipt-data": receiptString, "password": "your_shared_secret"]
guard JSONSerialization.isValidJSONObject(requestDictionary) else { return }

do {
   let requestData = try JSONSerialization.data(withJSONObject: requestDictionary, options: [])
   let storeURL = URL(string: "https://buy.itunes.apple.com/verifyReceipt")!
   var request = URLRequest(url: storeURL)
   request.httpMethod = "POST"
   request.httpBody = requestData
   request.setValue("application/json", forHTTPHeaderField: "Content-Type")

   let task = URLSession.shared.dataTask(with: request) { data, response, error in
       guard error == nil, let data = data else {
           print("Error verifying receipt: \(error?.localizedDescription ?? "No data")")
           return
       }
       // Process the verification response
   }
   task.resume()
} catch {
   print("JSON serialization failed: \(error.localizedDescription)")
}

‍

The Receipt Decoded: Element-by Element

The responseBody JSON payload can be daunting (example), especially if the receipt belongs to an end-user with a lengthy past purchase history.

It turns out, that there are somewhere between 3 and 7 top-level keys in the verifyReceipt responseBody JSON data structure. Here are the keys:
‍

‍

responseBody

Some of the top-level keys are present only in certain circumstances. Here’s a summary of each top-level key, what it is, and when you should expect to see it in the responseBody:

Let’s dig into each of these top-level elements in detail, starting with response metadata keys: status, is-retryable, environment.

status

Upon received a response from verifyReceipt, the first thing you should do is check that status key. If the value is 0, the receipt is valid. Otherwise, an error occurred and you will need to interpret the status code to know what to do next.

ProTip: Notice that the resolution to a number of the status codes is to retry later. It’s important that your receipt validation service is robust enough to handle a wide variety of scenarios including: network timeouts, HTTP status codes such as 503, and also status codes embedded in the return payload of a  HTTP 200 response. In some of these cases, you may want to to support retry logic to try again immediately. If you still failed to validate the receipt, you may want to add them to job queue for a future processing attempt.

is-retryable

If the Apple status value is within the range of 21100-21199, the is-retryable key should be present in the response payload. Apple’s documentation says the type is boolean, but the provided values are 0 and 1, not the proper JSON boolean values of true and false.

environment

The environment value tells you which Apple environment the receipt was generated from.

Now let’s look beyond the metadata into the primary keys containing the responseBody’s substance: receipt, latest_receipt_info, pending_renewal_info.

receipt

The value of receipt, a key within the decoded receipt response, is a JSON object containing the decoded receipt data.

This key always exists, whether a user has made an in-app purchase or not.

In fact, if you follow the best practice and send receipt data from your app to a server you will end up storing and decoding (via receipt validation) many receipts, containing this receipt key with certain metadata even if there have be no in-app purchases.

Consider the history of the App Store. It was built atop the foundations of the iTunes Music Store. On iTunes, an email receipt was sent to the user whether the song or album cost money or was free. This lineage carried on to the App Store, where in the early days there were just two types of apps: paid and free.  

Once in-app purchases were added, additional context was introduced to this data structure. In fact, it contains the full context you need to understand the purchase.

Now, with the advent of subscriptions things have gotten a bit more complicated. Some context about the subscription in-app purchase exists in this data structure, but some does not. For auto-renewable subscriptions, you will find additional context inside the latest_receipt_info and pending_renewal_info top level keys which we go into more detail later in this article.

Jump to an element-by-element breakdown of the receipt data structure.

latest_receipt

The latest Base64 encoded app receipt. This field is only returned if the app receipts contains an auto-renewable subscriptions.

latest_receipt_info

An array of JSON objects representing in-app purchase transactions for auto-renewable subscriptions. This field is only returned if the app receipts contains an auto-renewable subscriptions.

ProTip: If your verifyReceipt request includes the field exclude-old-transactions set to true, only the latest auto-renewable subscription transaction will be included in this field in the response.

Jump to an element-by-element breakdown of the latest_receipt_info data structure.

pending_renewal_info

An array of JSON objects representing open (pending) or failed auto-renewable subscription renewals as identified by the product_id. This field is only returned for app receipts that contain auto-renewable subscriptions.

Jump to an element-by-element breakdown of the pending_renewal_info data structure.

responseBody.receipt

Let’s take a look at all of the possible elements you may encounter in the receipt JSON object.

adam_id / app_item_id

A unique 64-bit long integer generated by App Store Connect. This is used by the App Store to unique identify the app associated with the receipt.

In production, expect a unique identifier. In sandbox, this field will be populated with a 0.

application_version

The current version of the app installed on the user’s device at the time of the receipt’s receipt_creation_date_ms. The version number is based upon the CFBundleVersion (iOS) or CFBundleShortVersionString (macOS) from the Info.plist.

In the sandbox, the value is always “1.0”.

bundle_id

The bundle identifier for the app to which the receipt belongs. You provide this string on App Store Connect and it corresponds to the value of CFBundleIdentifier in the Info.plist file of the app.

download_id

A unique identifier for the app download transaction.

While not well documented by Apple, this unique value appears to be tied to the download transaction represented by original_application_version and original_purchase_date.

In production, expect a unique identifier. In sandbox, this field has been observed to be populated with a 0.

expiration_date

The time the receipt expires for apps purchased through the Volume Purchase Program (VPP).

expiration_date_pst

See expiration_date

expiration_date_ms

See expiration_date

in_app

An array containing in-app purchase receipt fields for all in-app purchase transactions.

original_application_version

The original version of the app installed on the user’s device. For example, if the current app version is 2.0 but the user originally had version 1.8 installed, this value would be “1.8”. For the current version installed, see application_version.

The version number is based upon the CFBundleVersion (iOS) or CFBundleShortVersionString (macOS) from the Info.plist.

In the sandbox, the value is always “1.0”.

original_purchase_date

The time of the original app purchase.

original_purchase_date_pst

See original_purchase_date

original_purchase_date_ms

See original_purchase_date

preorder_date

The time the user ordered the app available for pre-order. This field is only present if the user pre-orders the app.

preorder_date_pst

See preorder_date

preorder_date_ms

See preorder_date

receipt_creation_date

The time the App Store generated the receipt.

receipt_creation_date_pst

See receipt_creation_date

receipt_creation_date_ms

See receipt_creation_date

receipt_type

The type of receipt generated. The value corresponds to the environment in which the App Store or VPP purchase was made.

request_date

The time the request to the verifyReceipt endpoint was processed and the response was generated.

request_date_pst

See request_date

request_date_ms

See request_date

version_external_identifier

An arbitrary number that identifies a revision of your app. In the sandbox, this key's value is “0”.

responseBody.latest_receipt_info

An array of JSON object(s) found at latest_receipt_info contains in-app purchase transactions for auto-renewable subscriptions. This field is only returned if the app receipts contains an auto-renewable subscriptions.

ProTip: If your verifyReceipt request includes the field exclude-old-transactions set to true, only the latest auto-renewable subscription transaction will be included in this field in the response.

cancellation_date

The time of the subscription was canceled. This can happen for one of the following reasons:

1. The App Store or Apple customer support refunds the subscription transaction
2. A Family Sharing change causes the user to lose access to the subscription
3. The user upgrades to different product.

cancellation_date_pst

See cancellation_date

cancellation_date_ms

See cancellation_date

cancellation_reason

The reason for a refunded transaction. When a customer cancels a transaction, the App Store gives them a refund and provides a value for this key.

expires_date

The time a subscription expires or when it will renew.

expires_date_pst

See expires_date

expires_date_ms

See expires_date

in_app_ownership_type

Indicates whether the user is the purchaser of the product, or is a family member with access to the product through Family Sharing.

is_in_intro_offer_period

Indicates whether or not an auto-renewable subscription is in the introductory price period.

is_trial_period

An indicator of whether a subscription is in the free trial period.

is_upgraded

Indicates a subscription has been canceled due to an upgrade. Only present for upgrade transactions.

Check cancellation_date to determine when the cancellation occurred.

offer_code_ref_name

The reference name of a subscription offer that you configured in App Store Connect. Present when a customer redeemed a subscription offer code.

original_purchase_date

The time of the original auto-renewable subscription purchase.

original_purchase_date_pst

See original_purchase_date

original_purchase_date_ms

See original_purchase_date

original_transaction_id

The transaction identifier of the original purchase.

product_id

The unique identifier for the product purchased as configured for that product in App Store Connect.

promotional_offer_id

The identifier of the subscription offer redeemed by the user.

purchase_date

The time the App Store charged the user’s account for a subscription purchase or renewal.

purchase_date_pst

See purchase_date

purchase_date_ms

See purchase_date

quantity

The number of consumable products purchased. Included but meaningless in the latest_receipt_info data structure, which is for auto-renewable subscriptions only. Likely an artifact from Apple internally sharing data structures between responseBody.receipt.in_app and responseBody.latest_receipt_info.

subscription_group_identifier

The identifier of the subscription group to which the subscription belongs.

web_order_line_item_id

A unique identifier for purchase events across devices, including subscription-renewal events. This value is the primary key for identifying subscription purchases.

transaction_id

A unique identifier for a transaction such as a purchase, restore, or renewal.

If transaction_id and original_transaction_id match, the transaction is a purchase. Otherwise, the transaction is a restore or renewal.

responseBody.pending_renewal_info

The array of JSON object(s) found at pending_renewal_info for open (pending) or failed auto-renewable subscription renewals includes a number of possible fields. Let’s take a look.

auto_renew_product_id

The product identifier for the customer’s pending subscription renewal, if the user has downgraded or crossgraded to a subscription of a different duration for the subsequent subscription period.

auto_renew_status

The renewal status for the auto-renewable subscription.

If this value is “0”, the customer is showing a likelihood to churn out of the subscription at the end of the current renewal period. A best practice is to present the user with an attractive upgrade or downgrade offer in the same subscription group.

expiration_intent

The reason a subscription expired.

If this value is “1”, you may want to offer the user an alternative subscription or a “winback” offer.

If the value is “2”, you may want to prompt them to subscribe to the same product again since they churned involuntarily.

grace_period_expires_date

The time at which the grace period for subscription renewals expires.

grace_period_expires_date_pst

See grace_period_expires_date

grace_period_expires_date_ms

See grace_period_expires_date

is_in_billing_retry_period

Indicates whether the user’s auto-renewable subscription is in the billing retry period.

If the value is “1”, consider prompting the user to update their billing information.

offer_code_ref_name

The reference name of a subscription offer that you configured in App Store Connect. Present when a customer redeemed a subscription offer code.

original_transaction_id

The transaction identifier of the original purchase.

price_consent_status

The price consent status for a subscription price increase.

product_id

The unique identifier for the product purchased as configured for that product in App Store Connect.

Receipt Date Formats

Throughout the Apple decoded receipt payload, you will find three different date formats expressed whenever a date is provided:

• ISO 8601-like GMT
• ISO 8601-like PST
• UNIX Epoch Time in milliseconds.

What is a date-time format similar to the ISO 8601?

What is ISO 8601-like? Apple documentation refers to “a date-time format similar to the ISO 8601” and “an RFC 3339 date”. In reality it’s not strictly either. The timezone part of the string make it difficult to convert these string-based date formats into date time object using common libraries which except ISO 8601 or other common standards.

Why Apple uses this specific non-standard format is probably an esoteric story related to the origins of NeXT or WebObjects.

To dive deeper into these three formats, let’s take a look at the date found at responseBody.receipt.receipt_creation_date. This is date the receipt was created expressed in the ISO 8601-like format relative to Greenwich Meantime (GMT).

Each base date key has two modifiers: _pst and _ms with the ISO 8601-like PST and Milliseconds since Unix epoch representations.

responseBody.receipt.receipt_creation_date_pst is an ISO 8601-like date relative to Pacific Standard Time (PST). Please note, even though the timezone modifier is provided in the format America/Los_Angeles instead of a UTC offset, the date provided is indeed Pacific Standard Time. Your code needs to be careful during Pacific Daylight Time (PDT), since this value will still be a Pacific Standard Time date.

responseBody.receipt.receipt_creation_date_ms is when the receipt was created in the number of milliseconds since the Unix epoch time.  The _ms modifier for all date fields in an Apple decoded receipt is the far easiest to work with. Most modern languages can convert this to a native date time object out of the box or with commonly used libraries.

What's VPP?

VPP stands for Volume Purchase Program. It's essentially how Apple provides an App Store-like experience for educational institutions or businesses to acquire and deploy apps at scale. As it relates to this article, some receipt fields only show up or contain values for transactions that occur on the VPP store.

There is a Better Way to Manage Receipts: Don't

As this guide illustrates, understanding the decoded receipt is complicated. So is the code necessary to store, validate, and make meaning out of the decoded receipt so you can properly manage your paid customer base.

The esoteric and sometimes arcane receipt response is the result of years of change and new features bolted on to the App Store year after year. It’s incredibly complex to write rock solid code to manage receipts and leverage all the App Store ecosystem has to offer related to in-app purchase and subscription monetization.

That’s where Nami can help. We’ve built a complete service to help you sell in-app purchases or subscriptions. In addition to a variety of features, we handle all client and server side details involving the receipt. In fact, you also don't have to write a single line of StoreKit 1 or StoreKit 2 code.

Our code has encountered many of the hard to test edge cases you’ll see encounter over time if you do-it-yourself. Our service has extensive test coverage and operates at scale.

This means you can stay focused on building your app experience. If you’re interested in learning more, we’d love to chat.‍

As the world continues to rapidly digitize, businesses are relying on technology more than ever to operate efficiently and effectively. One crucial aspect of technology is software development, which has traditionally required extensive knowledge of coding and development processes. However, with the rise of no-code solutions, companies are able to create and maintain software without needing extensive technical knowledge.

A VP of Engineering plays a crucial role in the software development process, overseeing the technical team and ensuring that the software they produce is high-quality and meets business objectives. Here are some reasons why a VP of Engineering may want to adopt a no-code solution:

1. Faster Development Time
   
   One of the most significant advantages of no-code solutions is that they significantly reduce development time. This is because no-code platforms offer pre-built templates, widgets, and drag-and-drop interfaces that can be quickly customized to meet specific business needs. This means that engineers can focus on the more complex and specialized aspects of development, such as integrations and custom features, rather than spending time on basic coding.
   
2. Increased Collaboration
   
   No-code solutions enable team members with diverse skill sets, including those without technical backgrounds, to collaborate more easily. This is because no-code platforms have a user-friendly interface that anyone can use, regardless of technical expertise. This increased collaboration can result in faster development and better communication across teams, leading to a more efficient software development process.
   
3. Cost Savings
   
   No-code solutions can be significantly more cost-effective than traditional software development approaches. This is because they require fewer resources, including time and money, to produce the same result. By reducing development time and the need for specialized technical expertise, companies can save money on salaries and infrastructure costs, making it an attractive option for businesses looking to scale quickly.
   
4. Increased Flexibility
   
   No-code solutions are highly flexible, allowing companies to quickly adapt and respond to changing business needs. With no-code platforms, it is much easier to modify and update software, allowing businesses to stay ahead of the curve in a rapidly changing market. This flexibility can be particularly beneficial for companies that operate in industries that experience rapid technological advancements and changes in customer preferences.

No-code solutions are a powerful tool for companies looking to rapidly develop high-quality software while saving time and money. For a VP of Engineering, adopting a no-code solution can improve collaboration, reduce development time, increase flexibility, and ultimately help businesses stay competitive in an ever-changing digital landscape.

If you're a VP of Engineering responsible for a subscription-based mobile application, consider Nami's no-code paywall solution. Nami's platform enables you to monetize your content and provide personalized experiences for your users, all without requiring extensive coding knowledge. With Nami, engineering teams can quickly implement and customize paywalls, optimize the purchase experience, and track revenue metrics through a user-friendly dashboard. Plus, our platform is highly flexible, allowing you to adapt and iterate quickly as your business needs evolve. Sign up for a free trial today and experience why Nami's no-code paywall solution is loved by engineering teams.

When does Google Play payout to developers?  Play Store developer payout occurs approximately the same time each month.  Generally, it happens around the 15th of each month for the previous month’s sales.

Here’s what to expect for Google merchant payments (which include Google Play developers):

• Payouts occur on the 15th of each month
• If the 15th falls on a weekend, payouts start on the following Monday
• If the 15th falls on a holiday, payouts start on the following business day

Payouts are for net proceeds less Google’s Play Store commission.

Most payouts are conducted via Electronic Funds Transfer (EFT). Funds can take 2-3 business days to arrive in your account.

In some regions, payouts are via wire transfer. Funds takes take 5-7 business days to arrive in this situation.

👉Read more: Apple Fiscal Calendar Developer Payout Schedule

Google Play Developer Payout Calendar Resource

Here is an online Google Play store developer payout calendar resource you can bookmark that is updated for the current fiscal year. It’s also available in an downloadable PDF format.

       

       if(window.strchfSettings === undefined) window.strchfSettings = {};
   window.strchfSettings.stats = {url: "https://nami.storychief.io/en/play-store-developer-payout-schedule?id=785881016&type=26",title: "Play Store Developer Payout Schedule",id: "51b60849-ff21-4408-b48f-9543da3cae59"};
           (function(d, s, id) {
     var js, sjs = d.getElementsByTagName(s)[0];
     if (d.getElementById(id)) {window.strchf.update(); return;}
     js = d.createElement(s); js.id = id;
     js.src = "https://d37oebn0w9ir6a.cloudfront.net/scripts/v0/strchf.js";
     js.async = true;
     sjs.parentNode.insertBefore(js, sjs);
   }(document, 'script', 'storychief-jssdk'))
   
   👉 Accrued Revenue

Nami co-founder & CEO joined Jennifer Sansone, host of the The App Growth Show to talk about turbocharging in-app subscription revenue.

Here is the episode synopsis:

Hey, App Growth Community! Welcome back to the App Growth Show, where we host mobile experts to provide valuable and actionable insights on how you can grow your app. No matter where you are in your app growth journey, we are able to help you achieve your mobile growth goals. Today, we are so excited to be joined by Dan Burcaw, CEO of Nami. Nami is a unique product that lets app marketers like you to design and implement the perfect subscription model for your app and create happy subscribers. They are the easiest way to implement one solution and sell subscriptions everywhere you need to. Whether a mobile app, on your website, or even from a connected device, Nami has you covered with one unified view of your subscribers regardless of where the billing takes place.

‍

Listen on Apple Podcasts or visit the episode page.