blazedd

It looks like a fairly undocumented change in Blesta 4 includes a change in how plugins extend the API by their url. If you look at the docs here, it shows per 4.0: https://docs.blesta.com/display/dev/Extending+the+API You would make a request to: https://yourdomain.com/installpath/api/foo_bar.foo_bar_sprocket/create.json?vars[price]=1.99 Now you make a request to: https://yourdomain.com/installpath/api/foo_bar.FooBarSprocket/create.json?vars[price]=1.99 It appears that you now reference the class name, rather than the file name. Is there a way that docs can be updated to reflect these changes?

We would LOVE to support Apple Pay with Blesta, but they don't have good support for mixing both Merchant and non-merchant payments. Additionally non-merchant payments are currently required to have a payment notification. Our only option is to require a plugin to be used in addition to the module and that's really not good practice :/

@viablethought I'm happy to have helped. I'm still a little concerned about the messages you received before, but I'm glad to understood how the payment accounts got de-synced. More than likely it sounds like you have an install with a lot more mileage and the auto-recover function to find their stripe id couldn't find the correct Stripe Customer ID to use. To upgrade you first need to overwrite the files, while the gateway is still installed. After the files have been overwritten you can finish it up by visiting the Gateways page and clicking the Upgrade button. Voila, you're done!

@viablethought So, that's 100% what caused the desync for your users. One of the "problems" with a plugin system for any modular system like Blesta, Wordpress, etc is that there has to be a cleanup function which is run on uninstall. This prevents plugins from modifying your database permanently, even after you uninstall the plugin (long term or short term). In our system if it's the last company on your blesta install to have had the gateway: it will delete the database where its stores the stripe customer connections.

@viablethought How did you perform the upgrade? For example did you use the upgrade function or did you uninstall & install again?

We're wanting to develop and release the Paypal In-Context Payment form for Blesta. We've already worked on both a plugin, a merchant gateway, and have extensively used the API from within Blesta. We're starting to get a fairly good grasp on how most things work, but there's still some confusion regarding non-merchant gateways, which is preventing us from simply building the new gateway: Question: Is there any support for non-webhook/payment notification gateways? For example the In-context gateway will perform the payment and guarantee a response immediately via a server-side request. It's somewhat similar to how some Credit cards work, where you effectively create a hold on the payment and then record the payment with a token provided from Paypal: Create payment token to Paypal, which includes sensative information regarding the payment's details (return URL, cancel url, etc) Build form with Paypal's Widget Javascript onto page User logs into Paypal without EVER leaving your website at all. The user also submits payment (or cancels the payment) with the popup UI. The user will be redirected to either the cancel url or the return payment url based on their action. Neither url is a notification url for internal use as the user's browser is used, rather than a webhook or IPN. When the payment was submitted by the user you MUST send a finalization request to Paypal to secure payment. This request will return the results of the payment, rather than an webhook/IPN. Paypal does not send an IPN for in-context payments. Question: Could the class NonmerchantGateway methods buildAuthorize, capture, & void methods be used? I noticed that the Payment gateway has methods as listed above, in the base NonmerchantGateway class, however they are currently registering unsupported errors rather than being blank functions. Based on other code in Blesta core it appears these methods are not yet supported. I just wanted to confirm that this is the case and see if there was any expectation to make them available.

This is related to This Bug Report: http://www.blesta.com/forums/index.php?/topic/6732-currency-decimal-accuracy/

Thanks, I did not see the bug report!

Is there any potential for an update on this?

Blesta: Janitor Small Blesta plugin to automate cleaning of abandoned orders, invoices, and services. Installation Download the latest release version from our releases and then simply upload the janitor folder to ~/plugins directory on your Blesta installation. How it Works: Janitor creates two cron entries which can be configured both by the cron settings and by the direct plugin settings. All of the plugin’s settings are based on the time the order was created. It may be important that you not cleanup and cancel at the same interval if you expect the orders to be marked as cancelled for any amount of time. Both cron tasks will never cleanup any orders or services which meeting the following criteria: The order’s invoice has any amount paid towards it. The order’s service is active or already cancelled. The order’s invoice is completely paid and is already closed (database: invoices.invoice_date_closed) Cron Task: Cancel Abandoned Orders This task is designed to strictly check for open orders which have never had any payments attached to them. First, the task will cancel the order and then next, it will void the invoice with a message as described in the language file. This cron task will also cancel any services attached to the order. This part of the cron intentionally leaves orders, invoices, and services in the database, in the possible event of this data being used by sales automation, etc. Cleanup Order Database This task is designed to completely delete all related database entries related to the order. It will remove the orders database entry, the order_services entry, and provides you the option to either leave the services as marked cancelled, or completely delete the service from the database via the plugins options. Only canceled services will be deleted if this option is set. If the service on this task is any other status than canceled, as set in the ‘Cancel Abandoned Orders’ cron task, it will ignore the service entirely. Download: https://github.com/nodecraft/janitor/releases Issues/feature requests: https://github.com/nodecraft/janitor/issues

We are also investigating implementing a similar solution. Our design concept is to adhere to the following rules: Remove orders which have been fulfilled from the database, including attached meta data such as order_services. Assigned un-paid orders which are older than $x date (via config) to be "cancelled". Cancelled orders will have services cancelled and invoices voided. Delete "cancelled" orders from orders table older than $y date (via config), including attached meta data such as order_services Our goals are to remove the potential of database bloat as new orders are added, but not full-filled. Removing completed orders doesn't provide any additional value to companies as the order process is not transparent to staff. As far as we can tell the only value the order has is to stitch the invoices to a service to get the initial setup running and data retention afterwards is not relevant. We're just hoping to confirm that these facts are accurate so that we don't break any features by removing orders as they are completed or abandoned.

The Packages model has a method called getPackageItems which is what we use to get the items and currency. A basic request to /api/packages/getPackageItems.json with package_pricing and a non default currency

(prefix: I am one of the dev members which worked on this module). I'd be much more interested in helping with more 3rd party module implementations such as this one if I could provide it via MIT rather than supplementing the Blesta license directly. We didn't have a problem maintaining the license for this release as we really needed the functionality provided. It's difficult to be enthusiastic about contributing when you lose all claim to the work or license attributed.

On the `currencies.php` model there is a method `toDecimal` which is labeled as the "precision" of a currency. As I understand it the intention is to turn a float similar to "12.622222" into "12.62". The functionality it actually provides is via the AppModel->truncateDecimal method which is a `minimum` precision as per the documentation. This leads to raw pricing data without truncated precision as per the currency's database configuration. For example USD pricing will result in: { "id": "1", "pricing_id": "1", "package_id": "1", "term": "1", "period": "month", "price": "10.00", "setup_fee": "0.00", "cancel_fee": "0.00", "currency": "USD" } but pricing for GBP is { "id": "1", "pricing_id": "1", "package_id": "1", "term": "1", "period": "month", "price": "6.9834", "setup_fee": "0.00", "cancel_fee": "0.00", "currency": "GBP" } I believe the frontend or view layer of Blesta is obfuscating this minor problem from being apparent. It's a significant issue for identifying the accurate pricing when the Blesta API is being consumed directly.

This is a massive problem for us and ultimately means we cannot use Blesta. Not only is it a restriction to our income, but would require our staff to double their workload for providing support for our hundreds of customers. Another limiting factor that keeps us in WHMCS