In-depth integration tasks

These jobs are separate. Choose the operation that matches the data or outcome your application needs; none is an automatic prerequisite for every checkout.

Which kind of plan does the application need?

Service pricing-plan fields are copied into a resource billing/configuration record in the existing administration model. They are not publisher Plan/Pricing IDs and must not be supplied as member checkout item_key. This comparison describes the distinct meaning; it does not add an administration setup operation.

Currency labels, language list/detail and IP suggestions serve separate selection/display jobs. The admin-prefixed country/currency registrations remain guest-readable in this source; prefix alone does not establish authorization. Geoinfo can transmit the lookup and request IP to an external service and cache/log results; handle unknown suggestions without fabricating location.

What follows an account-request acknowledgement?

The creation example records an application for two websites and returns account_id 8001. That value identifies the application record. It does not establish a user account, member token or content entitlement. The acknowledgement does not confirm queue delivery or completion by the downstream handler.

Only if your application intends payment for this request, read the payment prerequisites, then the paired example using 8001. The provider calls create a customer and charge before the final unchecked save. A payment error can follow provider effects, while an acknowledgement can follow local persistence failure. Reconcile uncertain results with the integration owner before another attempt. No automatic payment, refund, account provisioning or content-access step follows.

flowchart TD
    A[Submit application] --> B[Save request record]
    B --> C[Attempt queue event]
    C --> D[Return request ID]
    D --> E{Application intends payment?}
    E -->|No| F[Retain acknowledgement]
    E -->|Yes| G[Submit ID and provider token]
    G --> H[Attempt token save and refresh]
    H --> I[Create provider customer]
    I --> J[Calculate amount and create charge]
    J --> K[Attempt result save]
    K --> L[Return payment acknowledgement]

This diagram shows the usual sequence. A failure can stop it after a record change or provider action. Queue failures can be caught, and failed token/result saves do not always stop the request. The payment acknowledgement carries no settlement status. Neither path creates member identity or makes an access decision.

Keep credentials with their own task

For a publisher Pricing purchase, use the separate User subscriptions and Pricing selection. These supporting tasks are not a required checkout sequence.