Tyson

Your success method should return (almost) the same data that is returned in validate. That should be described in the comments for that method. However, you don't need to validate the data, as it isn't used for processing any transaction. If the payment failed, the customer should be aware of that failure while they're still on CarrotPay's website, and they wouldn't be returned back to Blesta until the payment went through successfully. The success method assumes the payment was successful because they shouldn't be viewing the 'payment received' page if it weren't. In the unlikely case that they return to Blesta and your validation method determines the payment is invalid, it is probably because of one of the following: your validation method is not correctly determining the payment's validity someone modified the payment data enroute causing it to no longer be valid (e.g. man in the middle attack) The error message in that screenshot is shown because you had set it in the success method with: $this->Input->setErrors($this->getCommonError("unsupported")); By default, that 'payment received' page says something to the effect of "Thank You! Your payment is being processed." In order to see that message, your success method needs to return data. The 'payment received' page isn't designed to display anything besides that success message. While you can still set an error message to be displayed, I don't think it would be necessary. You can set a custom error message with: $this->Input->setErrors(array('payment' => array('failed' => "The payment could not be processed!"));

If you only want to change the structure, then you should keep the current CSS/script files because they will continue to be used on other pages. If you're making a completely new client template theme by redesigning the entire interface, then you can include whatever you want. You should note that extensions assume the client interface uses the default bootstrap theme, so those extensions would need to be updated as well when redoing all of the template files.

How did you send the proforma invoice to the client? Proforma invoices are only requeued for delivery if they were queued for delivery and sent before. If you don't click the "Email" checkbox when you create the invoice, then it was not originally queued for delivery. When it is later converted to a normal invoice it sees that it was not queued for delivery before so it will not be queued for delivery again. This is the intent of CORE-1561. The system also makes no distinction between how the invoice was created (by order, manually, etc.) when requeuing it for delivery.

Is your success method returning the same data (no validation necessary)? Status would be 'approved'.

It looks like the URL you're linking to is the problem. I see that each product is linked to .../order/main/index/... when it should be .../order/main/packages/... for a specific product. For example, this is a link to the third product. The order plugin may perform a redirect when it receives certain GET parameters for an order form, so that is probably what you are experiencing.

The documentation PauloV linked should be able to get you started on extensions for Blesta. I realize not every detail is covered, so it may be best to ask specific questions on what you're having problems with if you need some clarification.

That is a common error, usually set by a gateway when it doesn't support a particular action being performed, like refunds. Are you setting any Input errors?

Payments would be applied immediately to invoices that the gateway has returned, yes. No, it looks like you aren't passing the invoices back properly. Based on the URL you included: invoices=YToxOntpOjA7YToyOntzOjI6ImlkIjtpOjQ7czo2OiJhbW91bnQiO3M6NjoiOS42Nzc0Ijt9fQ== $get['invoices'] is still serialized and encoded. You need to decode and unserialize the invoices before returning them. It is possible to pay multiple invoices at once, and to apply partial amounts to each, so it is important to set these appropriately. Other gateways implement a helper method, usually called unserializeInvoices(), to set the invoices back into the expected format. The end result would look something like: return array( ... 'invoices' => array( array('id' => 1, 'amount' => 25.00), array('id' => 2, 'amount' => 5.25), array('id' => 7, 'amount' => 10.06) ) ... );

The callback URL is yourdomain.com/blesta_dir/callback/gw/1/paypal_payments_standard/ where "1" is your company ID.

The order system maintains a session for products that customers attempt to order. It's possible you can be redirected when adding a new product to the existing cart if it is not valid. For example, if you have a product in the USD currency already in the cart, attempting to add a product for a different currency would fail because only one currency can be used on an order. In that case, you would need to clear your cart before adding the other product.

It sounds like the payment could not be applied to the invoices, possibly because you did not specify which invoices amount to apply? So the transaction is added as a credit, and the cron finds credits on the system when it runs and applies them to any open invoices automatically--not necessarily to the invoices you tried to pay. CarrotPay::validate should return the field ' invoices ' containing each invoice ID and amount to apply to it. You may want to check the cron is enabled for Provision Paid Pending Services under [settings] -> [Automation]. If the invoice is paid in full, that task will automatically provision within the set interval.

Blesta doesn't provide a method by which to delete transactions from the system. A test environment (separate Blesta install) would be ideal rather than testing on your live installation. Developers with an owned license can request a dev license key for this purpose. However, you could manually delete records from the database from the `transactions` and `transactions_applied` tables. What are you trying to test? You can kill the script at run time with a call to die. e.g. print_r($variable); die; // script ends here

This sounds similar to another feature request. You could include any other specifics in that other thread so we can better judge how such a billing statement should work based on feedback from everyone.

There hasn't been much demand for those gateways that I'm aware of, so we haven't dedicated any time to integrating with them ourselves.

See the documentation for an example. Set the group_id and package_id query parameters to select a specific product by default.

Clients::create is one of those methods that does not accept a company_id parameter, and instead uses the configured company ID from the system. You probably received a false response because of an error validating the data (e.g. the username or email address was already taken). If you wanted to work with a separate company over the API, you would need to use a different API user by configuring API Access for that user under the other company.

In your Blesta installation, the language definitions are found under /language/. You will need to create a new directory for Norwegian under /language/no_no/. Then copy the English translations under /language/en_us/ into /language/no_no/ and begin translating the files. The definitions for the client interface begin with "client_". You must also include a file named "no_no" with the name of the language (i.e. Norsk, NO). As you mentioned, about 1/4 of the translations are available from the Translator, and you can add to those if you'd like instead. It is necessary to understand how the definitions are constructed to translate them properly, so take a look at the documentation. Also, extensions (modules, gateways, plugins, etc.) contain definitions that can be shown in the client interface, and so each of those will need to be translated separately.

How are you creating the clients? What methods are you calling? A lot of methods use the configured company ID in the system if one is required when it does not accept one as a parameter.

If the IPN is correct, check the gateway logs under [Logs] -> [Gateway] to see if a transaction was received from PayPal. If not, either one was not sent by PayPal, or it was not received by Blesta.

Yes, that is correct. And yes, you should use the callback URL in place of the return URL if the gateway doesn't distinguish between the two. Configure::get("Blesta.gw_callback_url") . Configure::get("Blesta.company_id") ."/carrot_pay/" . $this->ifSet($contact_info['client_id']) . "/" The customer will still be directed back to the "payment received" page in Blesta. You do your payment validation logic in CarrotPay::validate, which is called after CarrotPay responds to the callback URL. public function validate(array $get, array $post) { $hash = $this->ifSet($get['hash']); $amount = $this->ifSet($get['amount']); ... // Perform validation logic ... // Return these fields (your values will vary) return array( 'client_id' => $this->ifSet($get[2]), 'amount' => $amount, 'status' => "approved", // ('approved','declined','void','error','pending','refunded', or 'returned') 'reference_id' => null, 'transaction_id' => null, 'parent_transaction_id' => null, 'invoices' => array(array('id' => $this->ifSet($get['invoiceid']), 'amount' => $amount)) // An array of arrays, each referencing the ID and Amount of each invoice paid ); } Depending on whether the payment is valid, you return a different status. 'approved' for successful payments, or 'declined', 'void', 'error' if it failed. Choose what is most appropriate based on the response from the gateway. After you return data from CarrotPay::validate, the transaction is complete.

@Jonathan, Are you only looking to display the service/package price as the "Renewal Rate", or are you wanting this to be the exact total amount that should be charged (considering config options, taxes, and any coupon) upon renewal? Including the package price is fairly simple, but the latter is not.

The variable $logged_in doesn't exist in the view. It is not set, and by default Html::ifSet returns an empty string. This evaluates to boolean false. Your condition negates this value, so the condition is always boolean true. That is why your text is always shown.

Looks like the Root Web Directory is incorrect. The root web directory should be set to /home/site/public_html/, without /blesta/. /blesta/ is Blesta's installed web directory, while /public_html/ is the root web directory.

Blesta is more flexible in terms of the customizations you can create as a developer, and it probably helps that so much of the source code is unencoded. You could write a plugin to do just about anything with the system, and you can integrate with the API, which supports all public model methods. So I would say it is more developer-friendly than WHMCS is, although they certainly have more customizations currently available at the moment. Bootstrap markup has been increasing in use on websites for a while now, and WHMCS currently uses it as well. It's a good platform to work from for standardizing markup. I think WHMCS also incorporates Smarty templates to aid in their creation, which we do not. But with anything new, there's going to be a learning curve to overcome. Feel free to ask more questions if something isn't making sense.

The error is likely caused by the name of the class or directory. The class name of the gateway should be in camel-case format, while the directory name should be separated by underscores as described in the Programming Style Guide, following the gateway file structure. You can use the other gateways as reference. i.e. The class name "CarrotPay" means the directory it is within should be "carrot_pay" @ /components/gateways/nonmerchant/carrot_pay/carrot_pay.php Curious, are you a developer by trade? I ask because I have been tailoring my explanations assuming that you are familiar with object-oriented programming in PHP--classes, abstract methods, inheritance, etc., following the MVC design pattern that Blesta uses. If not, there is going to be a learning curve to overcome first. In CarrotPay::buildProcess, you would create a view, set variables to the view, and return the view. Setting variables can be done by calling set on the View object by setting a name for it in the view (first parameter) and the value (as the second parameter). e.g. (This is copied from the Payza gateway) $fields = array(); $this->view = $this->makeView("process", "default", str_replace(ROOTWEBDIR, "", dirname(__FILE__) . DS)); Loader::loadHelpers($this, array("Form", "Html")); //Sets sandbox or production URL based on "test_mode" parameter value. $this->view->set("post_to", ($this->ifSet($this->meta['test_mode']) == "true" ? $this->payza_sandbox_url : $this->payza_url)); $this->view->set("fields", $fields); return $this->view->fetch(); You would output the data in your view template under /components/gateways/nonmerchant/carrot_pay/view/default/process.pdt. The Form and Html helpers are used to simplify creating form fields and for outputting content html-safe.