Payments in apps: connect Stripe, GoPay and subscription billing correctly
A customer pays, closes the browser before returning to the app, and receives no access. Another refreshes the success page and triggers duplicate fulfillment. A dependable payment integration must work through delayed results, repeated notifications, failures, and changes after the initial checkout.
The payment button is the visible beginning of a larger operating process. Your application creates an order, connects it to a provider's payment, verifies relevant state, applies the appropriate access or fulfillment, and supplies records for customer support and accounting.
Stripe and GoPay can both be part of that process, but their services and integration details differ. Choose based on your business model, merchant eligibility, payment methods, markets, recurring needs, and the rules of the platform distributing your app.
01Check the app and purchase context before choosing a gateway
A web application selling a subscription, a mobile app unlocking digital features, and a mobile app taking payment for physical goods can face different requirements. Identify what the customer buys, where they use it, and which storefront or distribution arrangement applies.
Apple's current App Review Guidelines distinguish digital purchases from other categories and include storefront-specific provisions for alternative purchase links. Google Play's payments policy also sets requirements and eligible alternative arrangements. Review the actual product, region, and program conditions before assuming an external checkout is allowed.
These rules are not a universal ban on every third-party payment or permission for every app to redirect customers. Requirements can change and differ across markets. Make the decision with the product and distribution team before implementing a payment flow that must later be rebuilt.
For direct web payments, review merchant onboarding, business category, currencies, supported methods, settlement, customer support, and relevant legal requirements. The customer's country and the merchant's eligibility are related but distinct questions.
02Compare Stripe and GoPay through the operating requirements
Stripe offers payment and subscription-billing capabilities for supported businesses. Its global availability page identifies supported merchant locations. Review the specific services and payment methods needed by your account rather than inferring universal availability from a broad brand presence.
GoPay can be relevant for a business serving Czech, Slovak, or other suitable European customers. Its international-payment guidance describes regional acceptance settings and review for expansion. Confirm the actual merchant arrangement and customer regions instead of treating gateway languages as proof of worldwide eligibility.
| Requirement | Stripe review | GoPay review |
|---|---|---|
| Merchant and market fit | Supported business location, category, service and payment methods | Merchant approval, regional acceptance and methods for the intended customers |
| One-time checkout | Supported checkout flow and payment lifecycle | Supported gateway flow and payment state retrieval |
| Recurring payment | Billing model, subscription states and supported methods | Version-specific recurring contract, customer authorization and recurrence handling |
| Notifications | Signature verification, repeated events and current state | v4 webhook trigger followed by authenticated payment-state retrieval |
| Accounting and operations | Invoices, fees, payouts, refunds and integration ownership | Documents, fees, settlements, refunds and integration ownership |
Review total operating work as well as transaction charges. A billing service may provide capabilities you would otherwise implement, but it still needs integration and configuration. A payment gateway's recurring charge feature is not automatically a complete subscription, entitlement, tax, or accounting system.
03Create the order on the server and verify the result
Your server should define the purchased item, amount, currency, customer or account, and internal order identity. Validate the offer rather than accepting a price submitted by the client. Connect the provider's identifiers to that record so later events can be interpreted correctly.
Use a supported checkout or payment component and keep secrets off the client. Avoid collecting and storing card details casually. The integration pattern affects security and applicable payment responsibilities; using a provider does not mean every possible implementation has the same scope.
Treat the browser return as a customer experience step. It can show that the application is checking the result, but the customer may never return or may repeat the visit. Apply access or fulfillment from an authoritative server-verified state, with the relevant amount, currency, order, and provider account checked.
Provider verification differs. Stripe's webhook documentation describes signature verification and event handling. GoPay's API v4 hosted-integration guide treats the webhook as a trigger for authenticated server-side retrieval of the payment's current state. The browser return serves the customer-facing page. Follow the chosen integration's current contract rather than inventing a common signature scheme for both providers.
04Handle retries, duplicates and delayed state changes
Networks fail at awkward moments. Your server may send a request successfully and lose the response. A customer may retry while the original payment remains pending. Decide how the system recognizes the same operation and how it avoids creating another charge or fulfilling an order twice.
Stripe's idempotent-request documentation explains a provider mechanism for safely repeating eligible requests with the same key and parameters. Use the correct operation identity and documented semantics. That mechanism does not make your database, email, access provisioning, or accounting update idempotent automatically.
Notification processing needs its own duplicate protection and recoverable work. Persist enough verified information to process reliably, acknowledge delivery appropriately, and handle later failure without losing the task. Stripe does not guarantee event delivery order, so the handler must not depend on receiving every event in a convenient sequence.
Define transitions in your own state model. Pending, completed, failed, canceled, refunded, disputed, and settled are different concepts. Map the actual provider's states carefully and avoid reducing every event to a paid boolean.
Provide a controlled repair process. Support should be able to inspect the order and verified provider state, identify a failed entitlement or document step, and rerun the correct operation without duplicating payment or fulfillment. Keep that capability restricted and recorded.
05Model subscription access separately from recurring charges
A subscription combines an agreement, billing schedule, payment attempts, access rules, changes, and cancellation. Define when access begins and ends, what happens during a trial, and how failed renewal affects the service. Keep the customer-facing terms consistent with the implementation.
Stripe's subscription overview describes its billing lifecycle and states. Review the relevant events and configuration for your model. Subscription status and individual invoice or payment state need careful interpretation before deciding what access the customer receives.
GoPay's earlier recurring-payment guide describes arrangements and customer authorization for an earlier integration. Before moving to API v4, verify the current recurring-payment contract, supported methods and merchant agreement; do not assume legacy behavior carries over. GoPay states that migrating to v4 Checkout requires implementation changes, and its checkout guide defines the current flow. If your application owns scheduling, retries, plan changes, and entitlements, document those responsibilities explicitly.
Handle an expired card, additional authentication, an unsuccessful renewal, and cancellation in a way the customer can understand. Give an appropriate route to update payment details or resolve the issue. Do not continue making attempts without reference to the agreed terms, provider rules, and applicable requirements.
Plan upgrades, downgrades, partial periods, and refunds with the business owner. Decide when the new entitlement applies and how the financial adjustment is calculated. Test the chosen behavior instead of allowing a billing default to determine the product policy accidentally.
06Connect documents, refunds and settlements to the right records
A payment confirmation, provider-generated invoice, and legally required tax or accounting document are not always the same thing. Agree the required documents, issuing entity, currency, numbering, tax treatment, corrections, and retention with the people responsible for the relevant jurisdictions.
An invoice may exist before its payment, including in a subscription billing flow. Model creation, issue, payment matching and corrections separately. A confirmed payment updates the appropriate records; it does not define a universal time for issuing every document.
Avoid sending two conflicting invoices because the provider and accounting integration both create one. Define the source of truth and how payment identifiers connect to customer and order records. The customer should receive clear documents without needing to understand your internal systems.
Reconcile payments with fees, refunds, disputes, and settlements. Money paid by a customer may not equal the amount arriving in the bank, and settlement may happen later. Keep the relevant identities and explanations so finance can resolve a difference without guessing from the date alone.
A refund also needs application behavior. Decide whether access changes, goods are returned, credits are issued, or a subscription remains active. Handle partial refunds and subsequent events deliberately. Payment state should inform the operation without silently overwriting the agreed business outcome.
Keep sensitive information out of unnecessary logs and support screens. Restrict payment administration, protect API secrets, review access, and define incident contacts. Our API integration guide covers related concerns in reliable connections between systems.
07Test the complete operating flow before launch
- Define the purchase. Review app rules, merchant fit, product, terms and access.
- Map the states. Connect orders, provider verification, billing, documents and ownership.
- Test the exceptions. Exercise delayed results, retries, duplicates, failure and renewal changes.
- Operate and reconcile. Monitor processing, support repairs, documents and settlement differences.
Use the provider's appropriate test environment and a representative set of scenarios. Include a successful payment without browser return, a repeated notification, a timeout after request submission, a failed entitlement update, a refund, and an unsuccessful subscription renewal. Keep test and production credentials and notifications distinct.
Review the customer journey too. Show a pending state accurately, explain an unsuccessful attempt, prevent confusing duplicate purchases, and provide useful support references. Test that messages and documents correspond to the actual order and state.
Plan launch monitoring and a way to stop new purchases if the integration misbehaves. A payment feature is ongoing infrastructure: provider changes, disputes, subscription updates, accounting requirements, and incident response need named owners after the initial implementation.
08Questions about payments in applications
Can every mobile app use Stripe or GoPay for digital purchases?
No universal answer applies. Review the product, storefront, region, distribution and current Apple or Google requirements, including applicable alternatives and program conditions.
Which provider is better for our application?
Compare merchant eligibility, markets, methods, recurring model, operating responsibilities and total costs. Stripe and GoPay have different services and integration behavior, so assess your actual requirements.
Can the success page grant access?
Use authoritative server-verified state for access or fulfillment. The browser may never return or may return repeatedly. Check the linked order, amount, currency and relevant state.
Do Stripe and GoPay verify notifications the same way?
No. Follow the provider's current documented mechanism. Stripe describes signed webhooks. GoPay's v4 hosted flow uses a webhook trigger followed by authenticated retrieval of the current payment state. The browser return is for the customer page. Do not assume a common API contract.
Does an idempotency key prevent every duplicate?
It addresses eligible provider requests under documented conditions. Your notification handling, database updates, emails, access and document creation still need their own duplicate and recovery behavior.
Is recurring payment a complete subscription system?
Not automatically. Define agreements, schedule, failed renewal, access, cancellation, plan changes, documents and ownership. Decide which responsibilities the provider handles and which your application must implement.
What must finance verify after launch?
Confirm the connection between orders, payments, fees, refunds, disputes, documents and bank settlements. Review relevant jurisdictional requirements and provide a controlled way to investigate discrepancies.