How to configure and adapt Aimeos based shops as developer
Forum rules: Always add your Aimeos and PHP version as well as your environment (Linux/Mac/Win)
#4182 by pdanzinger
08 May 2017, 20:58
I'm using aimeos 2017.04 (with current composer patches, e.h. client-html 2017.04.6) with TYPO3 7.6.

My aim is to create a custom payment provider that displays a payment form after the customer clicks on "buy now" on the summary page. The form should then be processed by the payment provider and sent to an external API.

I'm displaying the form like this:
Code: Select allpublic function process(\Aimeos\MShop\Order\Item\Iface $order, array $params = [])
   $payconfig = [
      'someInput' => [
         'code' => 'someInput',
         'internalcode' => 'someInput',
         'label' => 'Stripe Token',
         'type' => 'string',
         'internaltype' => 'string',
         'default' => '',
         'required' => true,
         'public' => true,

   foreach( $payconfig as $key => $config ) {
      $attr[$key] = new \Aimeos\MW\Criteria\Attribute\Standard( $config );

   return new \Aimeos\MShop\Common\Item\Helper\Form\Standard($this->getConfigValue('payment.url-self'), 'POST', $attr, false);

The problem is, once the form is filled out, the customer is redirected to [checkout-page]/co/process/?ai[code]=Provider&ai[orderid]=42 and the form seems to be discarded. The page says "You will now be forwarded to the next step" and contains a form without an action, so the "Proceed"-button just refreshes the page.

The same happens when I try the Stripe gateway from ai-payments.

After the form is sent, the cs_order parameter is empty, causing Aimeos\Client\Html\Checkout\Standard\Process\Standard::process() to exit right away. Is this desired behavior, or am I missing something?
#4185 by pdanzinger
09 May 2017, 09:49
I just reproduced it with a blank setup:

- Windows 7, php 7.0.8
- Download TYPO3 8 LTS (aimeos distribution installation throws an error on 7.6)
- Install aimeos distribution 2017.04 and aimeos payments (16.10, but whatever) from TER
- Add stripe payment: Image

- Create order and fill in payment info: [host]/index.php?id=11&ai[controller]=Checkout&ai[action]=index&ai[c_step]=process Image
- Click on "Pay now", enter redirect loop: [host]/index.php?id=11&ai[controller]=Checkout&ai[action]=index&ai[code]=Stripe&ai[orderid]=2&ai[c_step]=process Image
#4186 by aimeos
10 May 2017, 08:47
Seems like the URL is empty and therefore it stays on the "process" page while the JS for that page posts the form over and over.

Can you add a few debug statements to
- (why the URL is empty)
- (if the URLs are available in principle)
#4187 by pdanzinger
10 May 2017, 11:23
OmniPay::processOrder() is never called.

When the form is displayed, process() calls getPaymentForm() instead of processOrder(). When the payment form is submitted, the payment provider isn't called at all.

If my understanding is correct, OmniPay::process() should be called that way:

When the form is submitted, none of these methods are called. Instead the html client exists prematurely at because the param 'cs_order' is empty.
This is how it looks in the debugger:
#4188 by pdanzinger
10 May 2017, 11:32
"Faking" the cs_order parameter seems to fix it, so that's probably the issue.
It seems to work fine when I replace
Code: Select all'payment.url-self' => $this->getUrlSelf( $view, $args + array( 'c_step' => 'process' ), [] ),

Code: Select all'payment.url-self' => $this->getUrlSelf( $view, $args + array( 'c_step' => 'process' ) + array('cs_order' => 1), [] ),

#4189 by aimeos
11 May 2017, 07:39
Thank you for debugging! That seems to be a side effect of merging the order and process step together in the last version.

Yes, adding the cs_order parameter should fix the problem but a second record in mshop_order is created as far as I can see. We have to find a way to avoid this.
#4190 by pdanzinger
11 May 2017, 10:41
Yeah, that's right. The problem is, I'm not really sure how it is supposed to work.

As far as I can tell, the additional order is generated in But the only call to the process method of the payment provider seems to be a few lines below at

The only way to solve this I can currently think of is to add a hidden input to and then add functionality to the Checkout\Standard\Process\Standard component to process the payment provider without storing the basket in the database, trying to create a new account, etc..

For example, this works fine for me, but I don't know if it breaks anything else (also github seems to have messed up the indents a bit):