Mobile Integration

Updated 2,594 Days AgoPublic

Actions

Google Play integration

Operations

1. Initial Purchase

Some action will be called on Dating Frontend when user purchases subscription.
User's purchase needs to be verified.
Idea here is to make transaction.init api call to Payment.
After transaction.init api call, we make transaction.finish api call to Payment.
Payment will verify purchase inside transaction.init api call and based on verification transaction.finish will succeed or fail.
Verification includes calling Google Play api - Purchases.subscriptions , get.
Both api calls (transaction.init and transaction.finish) happen inside 1 request, ie it is similar to how Credit Card payment flows, ie. there is no need to use notifications to create user's subscription - it is instant.

Verification is done using Purchases.subscriptions: get api call to Google.

Flow: {M6}

2. Rebill

Using rebill schedule on Payment.
Since we know when subscription should expire, we can schedule rebill at that time.
Rebill procedure will just check subscription status on Google and if subscription is expired - we know it is stopped on Google and we should stop it on Payment and on Dating (using notifications), otherwise - subscription is still active which means that the Rebill happened (Google does all billing).
We're using somewhat generous rebill schedule for start - allowing failed retries, third stops subscription.

Rebill will make this Purchases.subscriptions: get api call to Google.

3. Stop

Purchases.subscriptions: cancel is that. It should be valid for subscriptions (Premium).
It will just cancel subscription. Subscription will expire after currently paid period.

4. Refund

Purchases.subscriptions: revoke - this is Stop & refund option that we use. It will refund and immediately expire user's subscription.

5. Edit

TODO / TBD (limited options for subscriptions - defer call)

Server

Frontend

1. Initial purchase action

Parameters from mobile app:
Must have:

• packageName string The package name of the application for which this subscription was purchased (for example, 'com.some.thing').
• subscriptionId string The purchased subscription ID (for example, 'monthly001').
• token string The token provided to the user's device when the subscription was purchased.

Other parameters can be added as needed by Mobile app or server app

We use subscriptionId's like: m1_2534_2_premium, m1_2534_14_premium, m1_2534_160_premium
system_id.site_id.pay_item_id.payment_item_type - should be string that has meaning on server app.

Admin

1. Refund

Config mostly, maybe some smaller code updates.

2. Stop, Cancel

Config mostly, maybe some smaller code updates.

3. Refund

Config mostly, maybe some smaller code updates.

Payment

1. Initial purchase

Must:

• verify purchase : Purchases.subscriptions: get

2. Rebill

• get subscription status : Purchases.subscriptions: get
• send notification to Dating

3. Stop

• cancel subscription on Google : Purchases.subscriptions: cancel
• send notification to Dating

4. Refund

• refund and stop subscription : Purchases.subscriptions: revoke
• send notification to Dating

Transactions

Google deals with financial details, ie we do not get any transaction identifiers, amounts ...
For all operations that we save as transactions on Payment (initial purchase, rebill, refund) we can fill transactions table record.
Transactions details can be stored in fixed fields table (not using json) by having all fields for all responses for all api commands that we call (there should not be too many of them).
All possible response keys from these 2 apis should be keys in transaction details table:

• Purchases.subscriptions
• Purchases.products

Refund via Google api is only possible for last subscription charge. Other transactions can be refunded from some Google Admin

Google Parameters for each item

Each call to Google Play API requires 3 params:

• packageName string The package name of the application for which this subscription was purchased (for example, 'com.some.thing').
• subscriptionId string The purchased subscription ID (for example, 'monthly001').
• token string The token provided to the user's device when the subscription was purchased.

We get these values when initial purchase action on Dating is called, and then they are passed to Payment in transaction.finish call.
These values are per item. We can store them in some additional table (user_id + item_id + these params).

Google Authorization

Service account with key (json) from https://console.cloud.google.com/iam-admin/serviceaccounts/project?project=myproject should be parsed and filled to appropriate pp_params_* table

Testing environment

None

---

Payment API usage

TODO