关于Google Pay API for passes的限制及相关技术问题咨询

Hey there, let's break down your questions about the Google Pay API for Passes clearly, based on official guidelines and common implementation experiences:

General Limits of the API #

Here are the key restrictions you should be aware of when working with the Google Pay API for Passes:

• Pass Type Schema Constraints: Each pass type (loyalty, offer, gift card, etc.) has mandatory fields defined in its schema—you can't skip required fields or mix attributes from different pass types in a single pass object.
• Policy & Compliance Limits: You can't create passes that violate Google's policies, including counterfeit goods, misleading promotions, restricted services, or content that infringes on intellectual property.
• User Wallet Storage Limits: While there's no public hard number, Google imposes reasonable limits on how many passes a single user can store in their wallet to maintain app performance. Excessive passes may be flagged or removed.
• API Access Approval: Your project must go through Google's approval process to access the API. Certain advanced features (like custom pass templates) may require additional review before you can use them.

Specific Detailed Questions #

1. Number of Allowed Loyalty Categories #

There's no official public limit on the number of loyalty categories you can create. That said, it's best practice to keep categories logical and avoid creating redundant or excessive ones—Google may flag accounts with an unreasonable number of categories as potential abuse, which could lead to restrictions on your API access.

2. Daily REST API Call Quotas #

Quota limits can vary based on your project's approval status and usage history, but here's the standard baseline:

• Per-User Daily Quota: For most standard projects, the default per-user daily limit is around 1,000 requests. If you have a legitimate high-volume use case, you can submit a quota increase request through the Google Cloud Console.
• Project-Level Daily Quota: There's also a project-wide daily quota (typically starting at 10,000+ requests) that applies across all users interacting with your API integration.

3. Custom QR Codes in Emails for Pass Links & Compliance #

You can send pass token links via a self-generated QR code in emails, but you need to stick strictly to Google's design and usage guidelines to stay compliant:

• First, you must generate the pass link using the API's official endpoints (like the insert method, which returns the pass's shareUrl or addToGooglePayUrl—never use a manually constructed URL).
• You can embed this valid URL into a custom QR code, but you should also include a clear "Add to Google Pay" button alongside it to make the action explicit for users.
• Never use the QR code to redirect users to non-pass-related content, and ensure the pass matches what users expect when they scan it (no bait-and-switch tactics).
• This approach is allowed as long as it aligns with Google's intended use cases—for example, sending loyalty passes to existing customers via their registered email addresses. Unsolicited pass distribution or violating user privacy rules will get you out of compliance.

内容的提问来源于stack exchange，提问作者Wanming Hu