Lack of interest Better purchase visibility

[keithg]

See the bottom of this rambling post for my ask.

I have a client that wants to see who has tried to purchase what...and what some of them managed to actually purchase. This post drivels on for a while in the hope that people will understand the real world problems that our clients operational staff need to deal with.

It is great that XF provides several different builtin sample Payment Provider examples. If you dig through the code you can eventually figure out the XF purchase model. See this thread for some early thoughts https://xenforo.com/community/threads/how-does-the-purchasable-items-system-work.140158/ The existing example code base was very useful for my journey of implementing 3 different payment providers featuring 4 different models of payment flows. These were all African business partners. Ping me if you are working in that area, I may have some ideas.

Unfortunately the current native XF system provides minimal operational support for purchase tracking. Hence this enhancement request / suggestion.

We can all agree that XF is not intended to be an eCommerce system, but it is quite capable of serving as a payment gateway platform. I want it to be just a little better than it is. Through an evolution of employing "best of breed" I have a client that is using XF as their payment gateway to sell services provided by another well integrated system with the actual users managed by yet another system. Several inter-system bridges are employed to make this seamless for the end user.

All XenForo needs to do in this case is provide access to a payment gateway and then allow operations people to monitor / triage purchases.

And the operations people are not happy with the out-of-the-box XF experience.

The only native XF support for this area is the Payment Provider log. It provides a chronological list of things the gateway developer thought they should record. And my first attempt was lacking. After a flurry of beta buyers pounding the system I had to add extensive logging for all of the then known normal and edge cases - especially failures.

But the chrono payment provider log was not what the ops people wanted. The payment providers provided a dashboard detailing payments, not user operations.

The obvious XF answer was to expose the xf_purchase_request table to the operations people.

A swing and a miss. I was able to create a xf_purchase_request listing that my client initially loved, but it was lacking in state information. When was the payment attempted? What states did it transition through? What was the end result? Where / when did it fail?

What my client needs is the definition of a very basic simple generic purchase flow supported by XF with the ability to track the status of every purchase through the flow.

P.S. Please feel free to PM me with your thoughts or questions...

 

[keithg]

Some additional info as I work through my solution. My xf_purchase_request listing uses a template to display internal data. The extra_data field works great with the template system as it appears to be an array of values. Easy to pick the array entries out in the template. The provider_metadata field is useless. It was difficult to store data as I had to JSON encode and decode my arrays of data and now this data does not seem to be useable by the template system. Note that these two standard fields have different data types in
XF. Not sure why?

I am currently abandoning use of the provider_metadata field and will jam the provider stuff into the extra_data field.

P.S. I may have the internal field names above incorrect as I am doing this post from memory.

 

[keithg]

and a followup after completing yet another payment gateway...
The secret to the extra_data field is that it is declared as

'extra_data' => ['type' => self::JSON_ARRAY, 'default' => []],
'provider_metadata' => ['type' => self::BINARY, 'default' => null, 'nullable' => true]

while the provider_metadata is just binary. You can feed the an array of items to the extra_data field when saving an entity.

I am documenting this find here since I keep forgetting the secret sauce and I needed it for my current project. Which meant I had to find this thread AND THEN do a code search to determine how to proceed.

The current project involved the challenge of adding a second concurrent payment provider to allow sales of the same item in a second country. Different countries means different currency which means different pricing. This lead to a multi tier system design:

• ability to map a payment provider to a country
• ability to define a product type that has a variable list of country, currency, cost values
• ability at checkout time for the user to pick their country

Country - Provider map was implemented as a new Payment system option that I patterned after the censorWord stuff - nifty stuff to allow multiple entries to be created by the user but then all jammed into a single database field. But easy to unwrap and use.

Product support require some heavy lifting with the creation of a new entity type. I patterned this after the existing Tag stuff but also stole some censorWords concepts since I needed to allow multiple country - price values for each product. Once again all of the pricing info ended up in a single database field.

The multi country checkout enhancement was very easy since it was based upon my prior creation of a "paid forum" which allows any forum to be marked as "purchasable". A few template changes and we are good to go...

As always, if you have any questions, just ask...