Skip to main content
This information may be outdated. :::
Confirm with the rest of the team before considering this information as valid. :::

Stripe

For each type of events we have seperate PHP class to process IPN and make DB changes For Stripe 3 types of events we are using now

1. charge​

examples: charge.created, charge.succeeded, charge.refunded, charge.pending etc

When we receive charge type events, class Gateways::Stripe::Events::Charge.php will process it.

Call Stripe Charge API to get charge object with latest status

Insert charge object (payment) in payments table

For refunded charge object, status will be approved, but DON'T INSERT IT AS 'APPROVED', but insert it as 'REFUNDED' (just added an if condition to check if charge object has refunded property value)

(For MercadoPago, we dont need this If condition since , MercadoPago API will give payment status as 'refunded' itslef)

Some addition actions required here (actions in users_plans table based on new payment)​

If payment received is from a single or prepaid type user_plan, and if current status of user_plan is pending (_or paused and cancel too - need more check on it) - Approve the user_plan record

if payment received has refund property, and corresposnding user_plan record is in approved status, cancel user_plan, Also set refund_status as 'refunded' (if not done already)

if payment received with error status, and if corresponding recurring user_plans received similar failed payment tries X times , we can can cancel user_plan

If answer to above question is DON'T CANCEL IN GATEWAY, we can expect payments in coming month and if payment received is for recurring user_plan and status in user_plan table is pending, just approve it

2.customer.subscription​

examples: customer.subscription.created, customer.subscription.updated, customer.subscription.deleted

When we receive customer.subscription type events, class Gateways::Stripe::Events::Subscription.php will process it.

Call Stripe Subscription API to get subscription object with latest status

update subscription status (sanitized status - publicala status) in users_plans table

3.checkout.session​

examples: checkout.session.created, checkout.session.completed

When we receive checkout.session type events, class Gateways::Stripe::Events::CheckoutSession.php will process it

Call Stripe Session API to get info amount session

Call related api to get more data like gateway_key (subscription_id for recurring subscription or charge_id for oneOff payment) update gateway_key, gateway_meta_post (may be update UserPlan status too - need to check )

IMP Basically we use this events to avoid situations like when user not redirected back to publicala's return url and missing gateway_key problem (when user close browser or something wrong happend)

we can fill gateway_key by processing this events by cross checking session_id stored in gateway_meta_pre column before going to stripe page

MercadoPago​

currently we are processing payment IPN

When receive payment event with payment_id, call Mercadopago api to get latest payment object and insert into payments table

Some addition actions required here (actions in users_plans table based on new payment)​

If payment received is from a single or prepaid type user_plan, and if current status of user_plan is pending - Approve the user_plan record

if payment received has refund property, and corresponding user_plan record is in approved status, cancel user_plan, Also set refund_status as 'refunded' (if not done already)

if payment received with error status, and if corresponding recurring user_plans received similar failed payment tries 3 times , we can can cancel user_plan

if payment received is for recurring user_plan and status in user_plan table is pending, just approve it

Unprocessed IPN Records​

There are some ipn records which we dont't really consider, means no need of insert any payments or take any actions in userPlan record

  1. Mercadopago card verification payment transaction. We will receive IPN for MercadoPago card verification which we will set as processed with action as "mercadopago card verification transaction, no actions needed"

  2. Some MercadoPago "merchant_order" IPN notification will not have any corresponding payment. In those cases we will set ipn as processed with action as "There is no payment info from mercadopago api, no actions needed"

  3. Some IPN records will not have a users_plans_id becuase those payments are done outside publicala, Will recive ipn becuase those payments are done via same gateway account used in publicala, examples are

    1. Publicala acoount team pays "Revenue share fee" to the Tenant montly by using publicala gateway account. we will not able to find a user_plan record corresponding to it
    2. some tenant used their Gateway account in other applications (outside publicala). we will also receive for those payments , for which we will not able to find a user_plan

We will soft delete those ipn_records which are not processed, no users_plans_id assigned, older than 15 minutes

Configure IPN Notifications in thirdparty owned Gateways​

Stripe​

URL: https://{tenant_domain}/payment/ipn/stripe Events:

  • invoice.updated
  • customer.subscription.trial_will_end
  • customer.subscription.updated
  • customer.subscription.deleted
  • customer.subscription.created
  • charge.updated
  • charge.succeeded
  • charge.refunded
  • charge.pending
  • charge.failed
  • charge.expired
  • charge.captured
  • checkout.session.completed

MercadoPago​

Access: https://www.mercadopago.com.ar/developers/panel/notifications/ipn in third party owned mercadopago account and set the following parameters:

URL: https://{tenant_domain}/payment/ipn/mercadopago
Events:

  • payment
  • mercant_order
X

Graph View