Creating an external API call when changing order status

[treiman]

Hi,

 

I am on Prestashop 1.6.

 

I am creating a new payment module. The payment service provider suggests that the purchase is 'authorized' with them at the time of order creation, and that the purchase is only invoiced when the goods are shipped or delivered. To comply with this, I would have to create a HTTP POST request to the external payment provider's API when changing the order state from a custom state I have created to another state (default or custom, shouldn't matter I suppose).

 

Where should I create this functionality?

 

The second problem I have is that the second API call made for 'invoicing' should use some of the information used in the first API call that was used to 'authorize' (essentially a credit check) a payment. However, that information does not exist anymore after the order is created: the information used for the first API all exists in my validation.php front controller, but if I have understood correctly I can only add an order reference as an 'additional' variable to validateOrder(). Now, I suppose I could circumvent this my somehow encoding the information required in the latter API call ('invoice') into the order reference, but this does not seem like a clean solution. Is there some easy and/or clean way to store additional information in objOrder for later use when creating the order?

 

For clarity, my current flow looks like this:

 

1. Select payment method at hookPayment by entering one's social security number (used by the 3rd party API) and click the payment method

2. payment.php front controller displays payment.tpl from views/templates/front; this page contains a form that is used to send the 'authorization' request with the user's information and the total_paid to the 3rd party

3. The form from payment.tpl (front) is handled (form action) by validation.php front controller, which validates and creates the order. The order state is set to one of my custom states ('invoice/loan authorized').

4. -- THIS IS WHAT I AM MISSING -- Next the shop should trigger the second API call ('invoice') to the 3rd party API when the order status is changed to, say, 'Delivered'; the API call requires information such as the customer social security number, the purchased items, along with some other information - some of which can be fetched from the Order object and some of which cannot.

Edited July 26, 2017 by treiman (see edit history)

[bellini13]

Where should I create this functionality?

 

In your payment module, you would register a new hook and then react appropriately.  I would suggest using the actionOrderStatusPostUpdate hook

 

When your module receives the event, you can look at the new order status, and if the status meets your requirements (I assume you mean Shipped, not Delivered), then you would invoke the gateways API

 

Social Security number is considered non-public personal information, and I an very surprised that the gateway would require this.  I would certainly not advise you to store the SSN in your database, but I fear it would be the only way for you to satisfy their API requirements.

 

I would suggest that you have a conversation with the gateway, and try to convince them that they do not need the SSN twice.  If they received it with the original authorization request, there is no reason that you need to send it again.

 

Putting myself in the customers shoes, I would never give you my SSN during checkout.  Especially if I knew you were using an open source platform and storing my SSN in a database.  You are opening yourself to a can of worms and lawsuits if that information were ever stolen.

[Scully]

bellini13's answer is probably the best you could get. I fully agree with him.

Whatever information is needed at the end:

most likely you would need an own database table to store some basics of order processing/payment to ensure no order is processed twice.

 

As already said: every information you don't store is not "at risk". the more delicate/personal such an information is, the more i'd try to avoid storing it.