Loaded Commerce Community

My payment gateway (DeltaPay in Greece) requests 3 return URL's: one each for accepted, failed and cancelled payments.

The Deltapay contribution returns all three to the same page (checkout_process) but posts a 1, 2, or 3 to pass the proper message to the customer.

However, I can't get this work (customer always goes quickly from checkout_process to checkout_success and sees a "Thank you for your order..." message).

Is there a specific page for payment errors like rejected credit or cancelled transaction?

OR, has anyone documented the payment process?

OR, can anyone suggest what I might be doing wrong with the Deltapay contrib that causes it to fail?

Thanks for any help you can offer.

Bob

Bob,

There is no specific page for rejected or cancelled tansactions as such. The basic osCommerce presumption is that either the transaction will succeed, or its not an order. Go figure.

Where did you get the Deltapay module ??

David

David,

Sorry to be so late getting back to you-I'm back in the US traveling quite a bit for two months. (Sorry, no beta testing til I get back home.)

The DeltaPay module is from the osC contributions. The payment gateway very wisely returns the customer to your store. I saw the module work once in simulation mode (or at least I _think_ I saw it work), and when the simulation was for bad credit, osC displayed a nice "There was a problem with your credit card, please select another payment method" message, and the customer was put back into the the order process again.

If, as you say, this is not a stock osC/CRE page, I guess we'll have to make one. I can't have my DeltaPay customers being told their order was successful when their credit card has been rejected.

Like many others, I've been looking for a flowchart of the payment process so that writing/modifying payment modules wouldn't be such a chore. Documentation of the code is much wanted here.

Thanks again for your help.

Bob

David,

Just so that I would know that I'm not ALL crazy, I installed osc 2.2 and the deltapay contribution.

And sure enough, the payment gateway simulator returns the cancelled and error transactions to the shopping cart payment page (by way of checkout_process, I believe) with corresponding error messages on a red background.
Successful transactions go back to the checkout_success page.

I'll post screen shots of the pages with error and cancel messages later tonight, along with the program flow of the payment and return processand the URL's.

Now to figure out why it doesn't work in Loaded6.2.

(What a way to spend a vacation!)

David,

The Deltapay module DOES work with the osC's checkout_process.php ( $Id: checkout_process.php,v 1.128 2003/05/28 18:00:29 hpdl Exp $).

The reason that it does not work with CRE6.2 is that the following code is never called by 6.2's process.



Instead, this code is lost in a series of if statements pertaining to various supported payment gateways(around line 64); and because Deltapay is not built-in, this crucial function, the very function that posts/gets the error codes and displays the bright red error messages is always bypassed and the user is sent to checkout_success rather than back to checkout_payment to try again.

I hard coded the line into CRE6.2 and all is well (unless I broke something else by adding the line.)

I won't post this as a bug in the tracker because it may be peculiar to the Deltapay payment module, but I think that the developer responsible for maintaining the checkout_process.php code should be made aware of the problem, because it may break other payment gateway contributions, too.

Hard coding must be seen as a very temporary work around and not a permanent fix because it makes future patch copying dangerous.

If you care to see the screen shots of the working payment error messages in CRE6.2, let me know and I'll post them.

Keep up the good work. I'm making money with CRE and I hope you are, too.

try,
[php]
// if (!MODULE_PAYMENT_AUTHORIZENET_STATUS)
// {
$payment_modules->before_process();
// }
[/php]

If possible point me to module which you are using, may help me to suggest you more.

Kiran

Kiran,

I guess my last post wasn't clear.
I DID change the code in the checkout_process file so that the before_ process would always be called.
I did NOT change the AuthorizeNet code; I merely inserted my code before the AuthorizeNet block.
This DID solve the problem for my payment gateway.

My concern is that I had to change the basic CRE code and that if there is a future patch that corrects something else in the checkout_process file, I will have to install the patch, then go back and add my code again.

This is especially bothersome because the osC code ALWAYS calls the before_ process--the CRE modifications have broken the basic osC script.

My thought is that maybe putting the call to the before_ process inside all the if statements is not really necessary. But I have no way (nor inclination) to test all the various hardcoded payment gateways to check this.

If you know that what I have done (and what you suggested) will break something else, please let me know so that I won't be surprised when it pops up.

Thanks.

Bob

Hello tibc,

Can you tell me how you did the hardcode part???

I am trying to install DeltayPay on CRE 6.4.0.a but I cant get it work :/

I got redirection to deltapay site, entering my Credit Card info all going well, redirects me back to site with Result Code 1 but my order is not placed in admin panel


Thanks for any help you can offer.