TOPIC:

Payment gateways 1 year 3 months ago #245071

  • TheMuffinMan's Avatar
  • TheMuffinMan
  • Offline
  • Developer
  • Developer
  • Posts: 10064
  • Karma: 167
  • Thanks: 808
Hi,

it depends in what context you are using JRequest.
If this is executed in a form piece it will be available as it is a Joomla API call.
If not, let's say in a script that is not loaded within the Joomla context, you will receive an error.

Alternatively you can do this
if(isset($_REQUEST['poli_return']) && $_REQUEST['poli_return'] == 'true'){
   // your code
}

This will use the PHP built-in to retrieve url parameters.

Please Log in or Create an account to join the conversation.

Payment gateways 1 year 3 months ago #245082

  • Topic Author
  • Rokhi
  • Offline
  • Senior Breezer
  • Senior Breezer
  • Posts: 111
  • Thanks: 1
Thanks Markus
Just to recap:
we were working on a PoliPay gateway solution, and you were taking me through it a step at a time.
You gave me some example code to put in end submit, and that tested ok, then you gave me some code to put in the before form, which also worked. Then we were going to refine it a bit, put in some redirects/response handling stuff and so on, then the form crashed.
I have been trying to debug it but I don't have an overview of where all the pieces and scripts are assembled and how it all fits together - so I was a bit lost.

So I started playing with the code block to see why it failed
I put the whole before form example you supplied into another form and it did not crash, so I figure it's something to do with the whole form and some other code in it that's conflicting with the polipay response listener block.

I then removed the listener block and tried just using the JRequest::getVar() to populate another variable in the before form piece using a different input var
$token = JRequest::getVar('token','');

And that was ok, so I replaced 'token' with 'poli_return' and it crashed. So I figured the var name was the problem.

I tried mis-spelling poli_return and called it poli_reaturn, and that didn't crash the form.

So, I put the listener block back in and changed the argument in the first JRequest::getVar() call from poli_return to poli_reply and ran the form
if( JRequest::getVar('poli_reply', '') == 'true'  ){

    if(JRequest::getVar('poli_success', '') == 'true'){

        echo 'Your payment has been successful!';
No crash, so I changed the spec in the after submit to match
"MerchantHomepageURL":'.json_encode(JURI::getInstance()->toString()) . ',
    "SuccessURL":'.json_encode(JURI::getInstance()->toString() . '?poli_reply=true&poli_success=true') .'&record_id='.$this->record_id.',
    "FailureURL":'.json_encode(JURI::getInstance()->toString() . '?poli_reply=true&poli_success=false') .'&record_id='.$this->record_id.',
and it all worked ok. Made the call to PoliPay, completed the transaction and came back displaying the success text.

Now, why would the JRequest call spasm at the var poli_return? and how can I search the assembled form code to see why it's causing a problem?

I could just leave it at poli_reply and be done with it, but we have had a few strange errors during this process and I don't like spurious errors.

You might not remember, but in the after submit, I had to change the code you supplied originally to
//curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1);

ob_start();
curl_exec( $ch );
//$response = curl_exec( $ch );
//curl_close ($ch);
$response = ob_get_contents();
ob_end_clean();


and you commented at the time:

Btw, I am still baffled that CURLOPT_RETURNTRANSFER throws an error for you.


so maybe there is something else in the form build that is screwing things up. But where/how to track it down?

If you think it's not worth tracking that down would you mind just giving me some hints on the best way to handle the responses in the listener so the user comes back to an intuitive form. ATM we come back to the original form and that's ok on fail, but that would be confusing on success. I assume we redirect to another page/article on success, or go to another page on the form. What would you suggest as best practice?

Thanks for your help with this BTW.
cheers
Paul

Please Log in or Create an account to join the conversation.

Payment gateways 1 year 2 months ago #246380

  • Topic Author
  • Rokhi
  • Offline
  • Senior Breezer
  • Senior Breezer
  • Posts: 111
  • Thanks: 1
Hi
I've pretty much got this working. I just need to prevent the mailback and admin emails from firing if the payment fails or is cancelled.

I'm using the system mailback and admin emails.

Since the stripe and paypal implementations offer the switch to only email on success, I am hoping that mechanism is accessible around the submit_validate area.

Can you give me any pointers please?

Please Log in or Create an account to join the conversation.

Payment gateways 1 year 2 months ago #246404

  • TheMuffinMan's Avatar
  • TheMuffinMan
  • Offline
  • Developer
  • Developer
  • Posts: 10064
  • Karma: 167
  • Thanks: 808
Hi,

I assume you have a check in place for successfull payments.

As soon after you verified the payment, please call these 2 functions in your code and make sure to pass the right form id and record id ("send notifications after succecssfull payments" need to be turned on):
bf_sendNotificationByPaymentCache($formId,$recordId,'admin');							bf_sendNotificationByPaymentCache($formId,$recordId,'mailback');

Depending where in your code need to trigger this, you might need to require the helpers.php:
require_once(JPATH_SITE . '/administrator/components/com_breezingforms/libraries/crosstec/functions/helpers.php');

Regards,
Markus

Please Log in or Create an account to join the conversation.

Payment gateways 1 year 2 months ago #246424

  • Topic Author
  • Rokhi
  • Offline
  • Senior Breezer
  • Senior Breezer
  • Posts: 111
  • Thanks: 1
Thanks for your reply

We hadn't got up to checking for successful payments yet Markus.

i have set up a simple button for PoliPay which sets bfPaymentMethod and calls ff_Validate_submit

The after submit piece sets up the PoliPay curl call and uses the NavigateURL from the response to direct the form reload.

I guess you're talking about some action around that response within the after submit piece, but we had not got up to that yet.

What check should I put in?

The before form piece picks up the reload post vars and responds then, but by then the emails have been triggered, so I'm guessing the code you have suggested goes in the after submit - after the successful payment check (whatever that is) - right?

Since I'm not using the paypal or stripe implementations, just a button, I don't have a setting for "send notifications after successful payments" (Or I don't think I do....) so I think I need to set it by a function.

I have looked through your documentation and can't find a reference for bf_sendNotificationByPaymentCache.

I'm guessing it releases the response emails when the 'send notifications... ' switch has been set to off, so I probably still need to know how to set that switch by code - I assume it will be set in the before form piece.

You said the helpers.php might be required depending on where in my code I need to trigger the bf_sendPayment..., I'm afraid I don't understand that -which code block are we talking about? I would have assumed the after submit since you said to put the sendnotification calls after the payment verification,which I suppose should happen immediately after the curl response is available in the after submit??

Please Log in or Create an account to join the conversation.

Payment gateways 1 year 2 months ago #246469

  • TheMuffinMan's Avatar
  • TheMuffinMan
  • Offline
  • Developer
  • Developer
  • Posts: 10064
  • Karma: 167
  • Thanks: 808
Hi,

that function is not in the docs because it wasn't meant to be used for regular users.
But you _can_ use it, that's why I suggested it.

Let me try to explain it more detailed:

You are triggering a payment. Once this payment is done, you will get a response about the successfull payment. As far as I remember, you are checking for this response already.

Immediately after that curl response you gonna execute this (as long as the response is positive in terms of "payment was successfull").
require_once(JPATH_SITE . '/administrator/components/com_breezingforms/libraries/crosstec/functions/helpers.php');

bf_sendNotificationByPaymentCache($this->form,$recordId,'admin');							bf_sendNotificationByPaymentCache($this->form,$recordId,'mailback');

This will send admin and mailback emails that are marked to be "held back".

The "$recordId" in the params you will need to retrieve "somehow".

"Somehow means": You will need to pass the record id to the payment gateway (preferrably in an end submit piece, basically there where you call the gateway already). The payment gateway will then have to return the record id in its confirmation message back to your server (usually as url parameter).

I can only talk about the general process here, because I don't know the gateway you are using well enough. But this is a common principle among payment gateways and each have their own implementation for it.

In the Before Form piece, you add this to "hold back" the notification emails:
$this->sendNotificationAfterPayment = true;

This will actually prevent the emails from being sent until you have called the 2 function calls described above.

Hope I was better in explaning the process better this time.

Regards,
Markus

Please Log in or Create an account to join the conversation.

Time to create page: 0.052 seconds

BreezingForms Pro 1.4.7 for WordPress Released!

Available in the membership section.

September Discount!

Massive discounts on all subscriptions!

Get Your Subscription Here

Quick Links

Downloads

BreezingForms

ContentBuilder

BreezingCommerce

Templates

Documentation

BreezingForms

ContentBuilder

BreezingCommerce

Apprendre BreezingForms (French Community)

Apprendre et maîtriser BreezingForms par des tutoriels et exemples, le tout en français

breezingforms.eddy-vh.com

Questions et réponses sur les forums de l'AFUJ

AFUJ

Special Offer

Summer Sale! All subscriptions at a special price!

Includes prio support, all of our current and future Joomla!® extensions and Joomla!® templates for the duration of your membership.

Get it from here

3rd Party Discount - 25% Off

We help you to keep your costs under control. If you are a new member and purchased a form building tool from a different form vendor, then you'll get a 25% discount on our subscription plans.

How to receive the discount:

Send us a quick email to sales@crosstec.org with a proof of purchase (for example a paypal receipt), await payment instructions and enjoy your membership!