Payment gateway and recurring subscriptions

I need to integrate Membership to handle our national special payment cards. I cannot use PayPal or any of the existing payment gateway plugins.

I've created a gateway.epay.php file in the Membership plugins directory and I have this plugin working in the setup/configuration part and I can also receive payments. When I receive payment I am able to record this correctly in the transactions view by calling
record_transaction( user, subscription id, amount, currency, datetime, transaction id, some-text-status, some-note).

I am furthermore using do_action with parameters 'membership_payment_subscr_signup' and 'membership_payment_processed'. All this seams to work ok.

My question/issue is:
1. I have no records in future transactions - why?
2. Does Membership even support recurring payment?
3. If so - what methods should I look at to trigger my code that will withdraw the monthly amounts automatically from the users payment card?

Any small pointers to this will be highly appreciated.

  • Philip John

    Hiya!

    1. I have no records in future transactions - why?

    I'll have to defer to the developer on this one as I'm not sure exactly where that is.

    2. Does Membership even support recurring payment?

    Yep, absolutely - but the payment provider must support them too.

    3. If so - what methods should I look at to trigger my code that will withdraw the monthly amounts automatically from the users payment card?

    With PayPal, the gateway creates a subscription on PayPal's end so that PayPal manages the actual subscription. If epay supports subscriptions you'll need to use a similar method.

    Phil

  • Barry

    I have no records in future transactions - why?

    That section was added to the reports for payment gateways that haven't been implemented yet - if you haven't specifically put a record in there with a future date then you won't see any records shown.

    Does Membership even support recurring payment?

    It has be be implemented on a gateway by gateway basis as some payment gateways control their own recurring payments (paypal express, amazon, paypal pro, authorize.net) and some don't (google checkout, paypal single payments) and so need extra functionality added to the gateway to handle this.

    If so - what methods should I look at to trigger my code that will withdraw the monthly amounts automatically from the users payment card?

    You need to hook into the action that is fired when a member moves from one level in a subscription to another. You can use 'pre_membership_move_subscription' filter to perform the charge before the move, then return a true if the payment went through or a false if it didn't or use 'membership_move_subscription' to process the payment regardless, and remove the subscription in the payment gateway if it fails.

  • Deepthing

    Barry & Phil,

    Thank you very much for your comments which provides some clarity.

    My payment provider is a 'special case' as it is a national system we're using. It does have support for recurring payments in the sense that I (upon first payment) can provide information that the payment type is a subscription. By doing so I get a subscription token that I can use for charging recurring payment one month later - it's my job to initiate the withdrawal like an ordinary payment. From your answers I understand that the method supported in Membership is the payment provider automatically charges the amount and from the code it looks like you (only) fetch the information for display in Membership.

    My thought for moving forward is now that I:
    - Will use record_transaction -method for any call I make to the payment gateway. This is effectively just a log used for nothing.
    - I will make a daily cron job that determines what subscriptions needs to be renewed. The cronjob will try to charge the money and put the result in the transaction-log. Upon fail I just disable the access for the user (i.e. downgrade them to free-subscription and send them a mail).
    - I should basically NOT use the future transactions for anything. But if I do I should just implement fetching of my expected future withdrawals like you will do with PayPal.

    Do you think this strategy sounds is feasible or am I missing something?

    Thanks.

  • Barry

    Will use record_transaction -method for any call I make to the payment gateway. This is effectively just a log used for nothing.

    Yeah - it's primarily a double check to make sure that the gateways IPNs are firing, so I always have the gateways recording the transactions so I can quickly look and see what and when the last few were.

    I will make a daily cron job that determines what subscriptions needs to be renewed. The cronjob will try to charge the money and put the result in the transaction-log. Upon fail I just disable the access for the user (i.e. downgrade them to free-subscription and send them a mail).

    Sounds good, though I'd run it hourly with a record limit (say processing 50 members) then you aren't processing a huge number at once and risking php or server timeouts.

    I should basically NOT use the future transactions for anything. But if I do I should just implement fetching of my expected future withdrawals like you will do with PayPal.

    Yep, ignore those as you aren't going to need them.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.