Category: Shopping cart and payment

An upgrade of a 12.x site to 15.x broke the ability to pay quantities with decimal points (0.5 €) to paypal, which worked fine in 12.x

Changing the amount to 1€, it worked as expected in 15.x

With Plugin "MemberPayment"
---
UPDATE: CLosing it, since I haven't been able to reproduce in another PHP+MySL setup (php 5.6 + mysql 5.7, packages bundled with Ubuntu 16.04 64 bit, instead of using some XAMP version) . {sign user="xavi" datetime="2016-06-03T13:05:32+00:00"}

Tiki Wiki's payment options are VERY limited. Internationally, practically only Paypal is implemented (and there the sandbox is broken! Cf bug report on that).

Currently, there are no methods implemented to charge banking accounts and/or credit cards aside from Paypal, which faces rejection by certain customers, because of Paypal's intransparent conflict resolution methods.

Charging banking accounts will be complicated, at least in Germany, because the organisation of banks demands certified code.

In Germany, the Swedish Klarna enjoys steadily growing acceptance. Klarna has published their API, so integration should be possible.

https://developers.klarna.com/api/#payments-api-create-a-new-credit-session

For Germany, other popular services would be Sofortüberweisung or BillPay, the latter being a "classical" card processor.

Thanks
hman

Another good option to increase Tiki Wiki's payment options would be Payone. That is not :-) a subsidiary of Klarna, but a joint venture of the German savings banks (DSV group) and French Ingenico SA.

Payone could open ALL international payment options for Tiki...

https://www.sparkasse.de/unsere-loesungen/firmenkunden/e-commerce/payone.html (in German).

The API is open:
https://docs.payone.com/display/public/PLATFORM/API+Home

Thanks
hman

Add tablesorter UI to Payments list for easier filtering of real data when many payments done.

Currently there is even no pagination at all. So when many records are there, it's not easy to find who payed whet, when, by whom, etc.

---
We have a dbdump already with a few data on it (of real small transaction with paypal), that we could share with a dev willing to implement this feature, in case this helps the development with fake-ish but real transaction data from paypal in production, not sandbox.
At: http://15x.notre.website

Please, ask me, for instance, and I'll fetch a db dump for you with admin pw reset for you.

after paypal payment, the user is shown his own payment invoice as "outstanding" instead of "past", until new page refresh

cache should be cleared or something when paypal comes back to the user. so that the user sees his/her own payment in the tab "Past", and not in "Outstanding"

For some reason, the show.t.o instance here hist another error:
{CODE()}
Fatal error: DateTime::diff() must be derived from DateTimeImmutable::diff in Unknown on line 0
{CODE}
but that might be another story, since I'm not seing in another test server elsewhere where I did the same steps to reprocuce the scenario ( http://15x.notre.website ).

You can test payments through the shopping cart:
http://xavi-9794-5955.show.tikiwiki.org/tiki-index.php?page=cart+products

or through the plugin group membership (setup to smaller fees, since we are testing in production with paypal):
http://xavi-9794-5955.show.tikiwiki.org/tiki-index.php

u: admin
p: 12345

other users (user1 and user2, and groups group1 and group2 are created with expiry info for the payment to make more sense and expire after a few days, etc)


At least, the show.t.o will allow anyone to get the db dump to have a local instance for debugging more easily than starting from scratch.

Right now, group expiry just removes the user from the group.
In use cases of membership management in associations, or business, in which members pay a fee per year, this feature is needed for an easier setup without so much intervention of the admin in so many steps.

Scenario: NGO with 3 levels of users:
* A) "regular members", needing tyo pay fee FA
* B) "associated members" , needing tyo pay fee FB
* C) "students", needing tyo pay fee FC

2 levels of time-dependent fees for each group:
* first year you pay feee F*1
* from second year onwards you pay a different fee F*2

When the membership payment for a year is over, that user should be automatically re-assignable to another group defined in the group transitions, which should allow to set conditions for the trigger to happen:
* when group expiry happens
* when freeperiods frmo ((doc:PluginMemberPayment)) expire
* when some tracker field = some value, higher/lower than some date or other tracker field, etc. (this one is just brainstorming; it should be thought more {sign user="xavi" datetime="2016-05-27T10:51:06+00:00"})

This way, they can be requested to pay for the fee F*2, knowing that they have to pay FA2, FB2 or FC2. With current codebase, after gruop expiry, you do not know which group that user belonged to, and you can't offer that user the right fee to be payed for with plugin MemberPayment.


HTH

Among several, there is one very big limitation of the shopping cart:

It cannot handle currencies! I wonder why no one saw this before (and I have to add, when debugging the translation of Tiki, it did not occur to me either). Cart must store the currency linked to all products. The currency of the user must be user-selectable (Of course, at the admin's discretion, the set of available currencies must be limited). We need to modify the data structure. The currency MUST become a separate field, and with that the price becomes strictly numeric (It could and should be discussed if we make that integer in the small currency units, but display it with the decimal comman/point inserted) and the currency should be strictly the three-letter ISO code, but a representation of that could be selectable (€ for EUR for instance).

If user currency and currency of any stock item differ, currencies must be converted. Currency conversion isn't easy. The first and easiest solution is having fixed conversion rates. These MUST be prominently and transparently displayed to the user, as they become part of the contract between the user and the admin/owner of the Tiki. Also, some sort of fee for currency conversion must be selectable by the admin (0 of course being the default), and it, too, must be prominently and transparently displayed.

When fixed rates have been established, the next level of comfort might be automatically set/updated rates. For that, we would have to find a reliable provider. Also, since all providers might for some reasons fail to supply data at any given time in the future, a default minimum and maximum rate must be selectable by the admin.

At first, I thought this could have been overlooked because of a domination by the US, but then it crossed my mind that even Americans have the need for currency conversion, because they got US and Canadian dollars, and when they sell internationally, also Australian and New Zealand dollars...

In Europe it is much more complex. Most countries have the Euro, but not all. Great Britain does not, but now it's not even part of the EU anymore. In the German speaking countries we have Euros (Germany, Austria) and Swiss Francs. Even though Switzerland is also no member of the EU, the fact that a large portion of Switzerland speaks German leads to Swiss users using German Tikis, and vice versa.

When you go to Products (the main shop) and click on a product, you get the products's page (Product), but that does not have a backlink to Products. Ideally it should backlink to the Products page that lead there (could be paginated), but a generic backlink to Products would be sufficient. This breaks the user experience that the backlink arrow leads back to all pages that linked to the current one. The browser's back button, of course, still works.

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

In /lib/prefs/paymen.php is a completely wrong description for a feature (AnonShopperProfile), and it's obviously a copy&paste-error. In 390 you will find
{CODE(Colors="Tiki")}
'payment_cart_anonorderitems_profile' => [
'name' => tra('Anonymous order item profile'),
'description' => tra('Wiki page containing the profile for creating order items for anonymous users (page name must not have spaces)'),
'help' => 'AnonOrderItemProfile',
'type' => 'text',
'default' => '',
],
'payment_cart_anonshopper_profile' => [
'name' => tra('Anonymous shopper info profile'),
'description' => tra('Wiki page containing the profile for creating order items for anonymous users (page name must not have spaces)'),
'help' => 'AnonShopperProfile',
'type' => 'text',
'default' => '',
],
{CODE}

The description of AnonShopperProfile is an exact duplicate of the description of AnonOrderItemProfile...

On a tracker set a currency field and set it to display the currency symbol.

It should display $35.00 but it shows ¤ 35.00

{img fileId="1533" thumb="box"}

If in "payment" "Tiki credits" is used, then a click to see open purchases results in a Fatal Error:

Fatal error: Class 'CreditsLib' not found in MYDIRECTOPY/tiki-18.7/lib/payment/creditspaylib.php on line 9

I stumbled upon this while googling something else (the documentation of Tikis Paypal interface):

https://github.com/romoxi/BobShop

The claim is "BobShop is a shopping cart system for TikiWiki. "

So far I haven't taken a deeper look. Has anyone else seen this? Or tested? Advantages/disadvantages compared to CART? Is this independent development or are the authors known or identical with Tiki devs?

I am asking those questions, because
* I am looking for something that accepts more than just Paypal
* Tiki Credit Card integration is in it's infancy

Thanks
hman

Tiki has a basic ((Shopping Cart)). Let's take it to the next level: ((Multi-sided platform))

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

The field tracker type currency as a parameter "First or all" to display the currency symbol on the first row of a tracker list.

{QUOTE(replyto="Lindon" date="2017-03-19")}In accounting, it is the norm to show the currency symbol only on the first number and the grand total, e.g., in financial statements or other accounting schedules.{QUOTE}

It is working when displaying tracker list item in the tracker view list mode or the trackerlist plugin. (on Tiki17 ?)

Not in the plugin list (may be other) - sould be check on accounting and payment part of Tiki.

So that parameter is here but not usable to create accounting statement with Tiki tools.

Check instance

Once a checkout is intiated, manual payments can be entered (e.g. to take into account bank transfers or cash).

However, if you enter a non-integer value (and it does not make any difference whether you use a decimal comma (default in Gemany) or decimal point). Non-integer values are completely ignored, not even an error message is displayed.

To phrase this more clearly: It is not just the fraction that gets ignored, it is the entire numerical entry of the user that gets ignored (not stored -> loss of data), as soon as there is a decimal point or comma in it.

Also, it makes no difference whether or not the value is above or below 1.

I demoed this on the show2 instance that I created for the error that Calendar events cannot be edited, no need create yet another instance...

Thanks
hman

When you click on "Payments" and then click on a purchase, there is a listing of goods purchased, but the links point wrong. E.g. after purchasing item number 4, the link points to tiki-index.php?page=cart+product&itemId=4 which does not open product item number 4 when you click on the link. Instead you land on product number 1, looks like this is a default?

The sandbox option for payment method paypal doesn't work, yields https://www.sandbox.paypal.com/webapps/shoppingcart/error?flowlogging_id=1cfca85ccab80&code=BAD_INPUT_ERROR

Possibly because of API change. See https://developer.paypal.com/docs/api/sandbox/.

Thanks
hman

I'm testing the PayPal capabilities of Tiki and this is about the "memberpayment" wiki plugin : https://doc.tiki.org/PluginMemberPayment

Following the doc I used the plugin as simple as possible as well as other requirements;
https://doc.tiki.org/Payment


__Groups__
I created a group;
* Enabled "User can assign himself or herself to the group"
* Set Membership expiry, Number of Days to 365
* Set Pro-rata Membership to "year".

__Payments__
* Payment system: Paypal
* Currency: Euro
* PayPal ID: paypal email
* PayPal environment: Production
* Enable PayPal instant payment notification (IPN)
* Enable Payment data transfer (PDT)
* Set the Payment data transfer (PDT) token
* Redirect after PDT payment: https://dev.domain.org/BernardPremium_homepage

__Subscribe page__
I set a plugin:
{CODE()}
{memberpayment group="BernardPremium" price="1" returnurl="https://dev.domain.org/BernardPremium_homepage"}
{CODE}

---
Use cases
Notes: payment are completed in all cases and it create an row in the Outstanding table (tiki-payment.php#content_payment1-1)

If a member of the Admins group subscribe himself and do a manual payment: He is assigned to the group. The user is redirected to tiki-payment.php?invoice=nn (almost good)

If a member of the Admins group subscribe another user and do a Paypal payment: The user is NOT assigned to the group, he is not returned to the Tiki site automatically. If he clicks on "return to merchant" the user is redirected to tiki-payment.php?invoice=nn (bad)

If a registered user and do PayPal payment: The user is NOT assigned to the group, he is not returned to the Tiki site automatically. If he clicks on "return to merchant" he is returned back to "tiki-payment.php?invoice=nn" (bad)


While I'm not getting into the code I understand 2 mechanism are invoked and not working.
Group assignment
Returning from Paypal

I'm not sure if they are required together to have the user assigned.

I'm testing the PayPal capabilities of Tiki and this is about the "memberpayment" wiki plugin : https://doc.tiki.org/PluginRegisterMemberPayment

Following the doc I used the plugin as simple as possible as well as other requirements;
https://doc.tiki.org/Payment


__Groups__
I created a group;
* Enabled "User can assign himself or herself to the group"
* Set Membership expiry, Number of Days to 365
* Set Pro-rata Membership to "year".

__Payments__
* Payment system: Paypal
* Currency: Euro
* PayPal ID: paypal email
* PayPal environment: Production
* Enable PayPal instant payment notification (IPN)
* Enable Payment data transfer (PDT)
* Set the Payment data transfer (PDT) token
* Redirect after PDT payment: https://dev.domain.org/BernardPremium_homepage

__Subscribe page__
I set a plugin:
{CODE()}
{registermemberpayment group="BernardPremium " price="1" returnurl="https://dev.domain.org/BernardPremium_homepage"}
{CODE}

---
Use cases (Paypal payment is completed in all cases)

If a member of the Admins group subscribe himself and do a manual payment: I got a WSoD (https://dev.domain.org/tiki-payment.php). (bad)

If a member of the Admins group subscribe himself and do a Paypal payment: The user is NOT assigned to the group, he is not returned to the Tiki site automatically. If he clicks on "return to merchant" the user is redirected to tiki-payment.php?invoice=nn (bad)

If a registered user and do a Paypal payment: The user is NOT assigned to the group, he is not returned to the Tiki site automatically. If he clicks on "return to merchant" he is returned back to "tiki-payment.php?invoice=nn" (bad)

While I'm not getting into the code I understand 2 mechanism are invoked and not working.
Group assignment
Returning from Paypal

I'm not sure if they are required together to have the user assigned.

The payment feature should call PayPal in the language of the user. Currently, it only calls the English interface. While inside PayPal, users can switch language, but not in the part that is on Tiki. This starts with the "Pay now" button, which is unnecessarily English only.

{CODE(Colors="Tiki")}
<br><input type="image" style="display:block; margin-left: 15px" name="submit" src="https://www.paypal.com/en_US/i/btn/btn_paynow_LG.gif" alt="PayPal" title="{tr}Pay with Paypal{/tr}">
{CODE}

Obviously PayPal supports ISO country codes for that, so this call for the PayPal button should IMHO be pumped through tra(), so it can be localized, but also the country code user pref could be used here, so the button appears in the user's language and not in the site language.

There are several ways how a visitor of a Tiki could pay for goods and/or services, but Tiki supports almost none of them (Paypal is the only internationally accepted solution offered).

Besides credit cards, which Tiki does not support, several national solutions exist (that Tiki doesn't support either). Most of them are proprietary API, every bank has it's own. From the European Payment Initiative Council comes a new standard: SEPA request to pay.

It's a standardized way that streamlines the process. The user doesn't have to transfer money by having to open up his/her online banking, entering the very long (and thus error prone) IBAN, and the Tiki doesn't have to deal with differing APIs for different banks.

SEPA request to pay works like this: When the shop requests payment, this is being transferred via SEPA request to pay to the user's bank, which adds the request to the homebanking of that user, so the user can confirm the payment within the trusted environment of his/her homebanking, an error free and trusted way to deal with payments. From the Tiki point of view, the unified specification is a big plus: Only one code base needed...

The standard can be found at this [https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2018-05/EPC069-12%20v2.1%20Quick%20Response%20Code%20-%20Guidelines%20to%20Enable%20the%20Data%20Capture%20for%20the%20Initiation%20of%20a%20SCT.pdf|link], the homepage of SEPA request is [https://www.europeanpaymentscouncil.eu/what-we-do/other-schemes/sepa-request-pay-scheme].

Plugin Add to Cart is used in conjunction with a tracker item (the product).

In the tracker item we already have price and description however the Plugin Add to Cart need those field to be set manually. Extra maintenance and... dull :)

The Plugin Add to Cart should be able to use the product information.

The ultimate feature of Amazon and all the e-commerce shopcart systems is the one known as "Customers who bought this item also bought .." or "were also interessted in ..".
The feature would show objects or items that were viewed or bought by previous users in conjunction with the actual item or object.

Idea:
Applied for tiki a new plugin "Relation By Views" would allow to list related wiki pages (or even other objects) in a page likewise to existing backlinks and alias plugins as well as semantic links.
Though, the information is based on previous view counts / his of wiki pages (or other objects) that have been hit by users wihtin the same session as the actual wiki page / object.

The enhancement is obvious: we would make a step further to get implicit relations between pages / objects based on user behaviour.
Just as the advantage in ecommerce is crossselling, we would provide cross-links and encourage readers to have a look to further pages / objects.
In regard to enhancements of the basic shopping cart feature in Tiki 5, this plugin could even be used as a real "customers were also interessted in" feature.