Max

I expect that to get the job done, yes. Don't think any other output is sent.

We are talking about the callback URL that gets called on notifications... The controller handling that will call validate() of your payment module. I do not think there is any technical reason preventing you from echo'ing inside that method, even though it may not be clean design.

Doesn't just using echo like in your example code work? It may not be good MVC design, but if that gets the job done...

Probably too late now, but next time make sure to do a "stat /path/to/file" before you delete the file. It shows the file modification time to the second. Looking up that exact time in your webserver access log can sometimes help finding a compromised script, if that was used to install that file.

Problem with using the callback URL for clients is that the Blesta code is then redirecting the client to /client/pay/received/yourgateway, and not preserving any added parameters (like /client_id in your example) /blesta/app/controllers/callback.php // Process the payment notification from the gateway $this->GatewayPayments->processNotification($gateway_name, $this->get, $this->post); // Redirect any client back to the payment received page if ($this->Session->read("blesta_client_id") || $this->Session->read("payment")) $this->redirect($this->client_uri . "pay/received/" . $gateway_name); Can workaround this by storing the added parameters in a session as well (which is what we did in our proof of concept Omnipay module), but would be nice if the Blesta core code was fixed to just append any additional parameters as well when redirecting.

Depends if the gateway also uses that information to notify you of charge backs later. In the case of unauthorized card payments, EU consumers have 13 months to fill one.

If you run into any problems, you can also look at omnipay_nonmerchant_gateway.php in my Omnipay module as full example. That is using the same methods.

I would be relucant to add columns to Blesta's own tables, as that could potentially give problems with updates, and other third party modules. Safer to create a table of your own for that (like the gateway_sessions table in my example)

$redirect_url = Configure::get("Blesta.gw_callback_url") . Configure::get("Blesta.company_id") . "/payzone/".$this->ifSet($contact_info['client_id']); Would append an unique ID for the transaction (like in my example), not client_id. As long as it is using the callback URL you set when initiating the transaction (including the unique id you appended) for notifications I do not see the problem. Or is it using a global notification URL that cannot be set on a per transaction basis?

You misunderstood me. I suggested storing the token in the database, but set an id in the callback URL so you know which database record to fetch.. With my example methods mentioned above. function buildProcess(array $contact_info, $amount, array $invoice_amounts=null, array $options=null) { $sessionid = $this->createSessionID(); $callbackurl = Configure::get("Blesta.gw_callback_url").Configure::get("Blesta.company_id")."/".strtolower(get_class($this))."/".$sessionid; // // ...add code to initiate transaction with gateway using their API here... // $data_you_want_to_store = array('client_id' => $contact_info['client_id'], 'invoice_amounts' => $invoice_amounts, 'token' => $token_received_from_gateway); $this->putSession($sessionid, $data_you_want_to_store); // redirect user to gateway header("Location: $url_received_from_gateway"); exit(0); } function validate(array $get, array $post) { // fetch information from database using sessionid from URL $data = $this->getSession($get[2]); if (!$data) return; // // ...decrypt response from gateway with $data['token']... // }

Does the gateway sends anything else upon return, besides the encrypted data? E.g., an unencrypted transaction id you can set? If not you will need to append a sessionid to the callback URL: $callbackurl = Configure::get("Blesta.gw_callback_url").Configure::get("Blesta.company_id")."/".strtolower(get_class($this))."/".$sessionid; And access the sessionid later with $get[2] Which works for gateway notifications, but not for the client redirect (because Blesta redirects the user to a different page without preserving the added /$sessionid) for which you have to use a normal session as workaround. Store the sessionid, token, invoice_amounts and client_id in the database. Either as separate fields (which would require a separate table for invoice_amounts like in Cody's database scheme), or by putting all data in an array and serializing that to a TEXT field with serialize(), like in my example code.

I don't know if that's a problem with GoGetSSL, but our experience with a different provider in our current (custom) billing system is that the API methods offered to check CSRs often leaves to be desired. It only checked if the CSR is well formed. But did not check if the public key used is at least 2048 bit -which is a hard requirement nowadays- and the CSR still got rejected with a cryptic error message when the user actually proceeded with the order... So it's better to do some basic local checks yourself as well, among the lines of: $key = openssl_csr_get_public_key($csr); if (!$key) // print error csr is not valid $keyinfo = openssl_pkey_get_details($key);if ( $keyinfo['bits'] < 2048) // print error key is not 2048 bits In our current system, we prefer not to allow an order to be placed without one either. More or less a business decision to prevent extra support and administration for refunds, if they do not manage to create one.

Somewhat related feature request: http://www.blesta.com/forums/index.php?/topic/4498-non-merchant-gateways-option-to-offer-more-than-one-entry-in-payment-method-list/ Right now Blesta only displays the name of the non-merchant gateway (e.g. 2checkout, bitpay) in the payment methods list, while most customers are expecting the actual payment methods (credit card, bitcoin) they want to use listed instead. And in that case it should be possible to have more than one entry in the list as well (single non-merchant gateway, can handle multiple payment methods)

TS may indeed need to remove the dechex() if his gateway does not support hexadecimal digits in the transaction id either. >A better solution would be something like: > >gateway_sessions >uuid, gateway_id, expire_date > >gateway_session_invoices >gateway_session_uuid, invoice_id, amount > >Then you simply pass the uuid to the gateway and read it back on the response. My code is esentially using shortened 96-bit UUIDs by default. (32 bit time + 64 bit random) Using a flexible varchar(255) as id in the database though, so that descendant classes can override the protected _generateSessionKey() method and use a different scheme, if there is a need to. >gateway_session_invoices >gateway_session_uuid, invoice_id, amount Prefer supporting storing arbritrary data using serialize() (or json_encode()) to a TEXT column. While Blesta only needs the array of invoice_ids, some gateway modules may have a need to store extra information as well. Many modern non-merchant gateways require that you initiate the transaction with an API call, before redirecting the user to the gateway. Sometimes that call returns extra information you need later on to verify the transaction.

What is the grey colored error message under the "This webpage is not available" line?

That would do as an intial check. Think you should also support verifying the entire e-mail address by sending an e-mail with activation code/link to it. Some registries require that you have verified the e-mail address of the customer when registering domains. Not sure about the prevalence. Have my doubts about what else is being said on that page as well: Ah, state of the art spam filtering from the century that AOL still provided free frisbees. Checking MX records, to see if the sending server is authorized for that domain? How is that ever going to work? Major providers like Gmail use server names like mail-lb0-f173.google.com for their outbound e-mail, which are certainly NOT mentioned in the MX records for gmail.com nor google.com. It is more common to use SPF for this purpose instead. But even that is too unreliable as sole indicator to filter e-mail, as it causes way too many false positives with e-mail forwarding and mailing list...

While it is customary to have one, it is not a requirement, if you only have one mail server. Foreign mail servers wanting to deliver to your domain will simply use the A record if there is no MX. RFC 5321 SMTP

Only afterwards. Not when a transaction is being initiated at a non-merchant gateway.

Order id? Didn't knew Blesta understood the concept of orders. Only thing that gets passed to payment gateways is an array of invoices. Serializing that, and passing that to a gateway is asking for trouble, because many gateways impose a character limit (especially European gateways, because they tend to include the transaction ID on customer's bank statement) It may work fine during your testing while paying single invoices, but you risk that if a customer has a longer list of overdue invoices that he finally wants to pay, it will fail. I proposed introducing a common database table for storing payment transaction information for this earlier, but the team didn't feel anything for that. So yes, anyone wanting to properly implement a non-merchant payment gateway module will need to create their own... Can use functions like this: protected $gwname = "My gateway"; function install() { $r = new Record(); $r->setField("id", array('type' => "varchar", 'size' => 255)) ->setField("gateway", array('type' => "varchar", 'size' => 255)) ->setField("expire", array('type' => "datetime")) ->setField("value", array('type' => "text", 'is_null' => true)) ->setKey(array("id","gateway"), "primary") ->create("gateway_sessions", true); } protected function getSession($id) { $r = new Record(); $row = $r->select("value")->from("gateway_sessions") ->where("id", "=", $id) ->where("gateway", "=", $this->gwname)->fetch(PDO::FETCH_ASSOC); if ($row) return unserialize($row["value"]); else return false; } protected function putSession($id, $data) { $r = new Record(); $r->where("id", "=", $id) ->where("gateway", "=", $this->gwname) ->update("gateway_sessions", array("value" => serialize($data))); } protected function createSessionID() { $r = new Record(); $expires = date("Y-m-d H:i:s", time() + 86400 * 14); for ($try = 0; $try < 10; $try++) { try { $key = $this->_generateSessionKey(); $r->insert("gateway_sessions", array('id' => $key, 'gateway' => $this->gwname, 'expire' => $expires)); return $key; } catch (PDOException $e) { } } throw new Exception("Error creating session"); } protected function _generateSessionKey() { return dechex(time()).dechex(crypt_random()).dechex(crypt_random()); } (Using an ID based on time, rather than an auto-increment, so that the number is unique, and doesn't start at 1 again if you reinstall Blesta, or if you use the same gateway with other software)

Probably inspired by Vmware's software licensing model. They charge providers based on the average reserved memory usage.

Would be nice if the HTML invoices looked the same as the PDF ones though. Perhaps consider replacing tcpdf with a HTML to PDF convertor like dompdf.

Note that English is a West Germanic language as well. Still not something they (like to) speak in Germany.

They do not speak Dutch in Germany...

Do wonder about that. Maybe have a poll? Same culture here. Prices have been going down over the years, and if we didn't extend that to existing customers they would think we are screwing them over, and act accordingly. Rather lose short term profit, than a long term customer. Different prices per customer do are common here if orders go through some kind of quote process, but not so for businesses that have prices listed on their site.

FYI the Dutch banks have just released the eMandate technical specifications. Allowing you to redirect the customer to the online banking website of his own bank, and confirm the direct debit authorization there with the 2 factor authentication system banks use. This is similar to how iDeal works, but for recurring payments. http://www.incassomachtigen.nl/wp-uploads/eMandates-Implementation-Guide-B2C.pdf http://www.incassomachtigen.nl/wp-uploads/eMandates-Creditor-Libraries-Integration-Manual.pdf It replaces paper authorization forms that the customer needs to print, sign and return. Only handles the customer giving you authorization part though, you then still need to use PAIN XML batch files to actually collect the funds. And still requires Blesta core changes to implement.