VAT issue with payments!

Workflow these users are taking when this happens (as i mentioned, this does not happen all times)

• User registers on the site.
• During registration, our logic determines the country.
• During registration approval we ensure that the declared country is correct by checking the user IP (We do not accept registrations if VPN, Proxy, Tor etc has been used).
• After registration approval, an auto action is triggered "onAfterUserApproval" and populates the cb_subs_inv_* invoice fields automatically. These invoice/profile fields already exist before the user logs in for the first time or reaches CBSubs checkout.
• The user logs in and activates/upgrades a subscription.
• CBSubs creates the payment basket. Sometimes the basket is created correctly with all address_* fields populated and VAT calculated... but sometimes the basket is created with all basket invoice address fields NULL (address_country, address_country_code, address_city, etc.) and tax/VAT becomes NULL

In the examples I checked:

• The users were logged in (otherwise they can not access the plans).
• They already had cb_subs_inv_* fields populated before basket creation.
• The issue happened during subscription activation/upgrade flow.
• A second basket for the same user minutes later could work correctly.

Are both plans marked exclusive?

None of our plans is exclusive.

Then I don't understand how you're getting their address to begin with.

They provide their address during registration and cb_subs_inv_* invoice fields are populated automatically by the auto action as explained above (Workflow).

At any rate I'll be looking into addressing this. Basically a "Read Only" mode for invoice address that only lets them supply one if they don't have one. So your auto action behavior would cover that requirement forcing it into read only while allowing the mandatory invoice address logic throughout CBSubs to function properly, which would help reject incomplete baskets so you never have to deal with these refunds again. If you're using Read Only profile fields already it'll be similar to that experience

One additional concern about the “Read Only” invoice-address approach:
If the basket invoice-address snapshot is not populated correctly, and the fields are read-only, then the user cannot fix the problem themselves. The payment would simply be blocked and the user would be stuck.
So for our case, “Read Only” is acceptable only if CBSubs reliably initializes the basket address from the existing cb_subs_inv_* profile fields before validating/blocking payment.
Otherwise the result would change from “payment reaches PayPal without VAT” to “customer cannot pay at all”, which is safer for VAT but still a serious checkout failure.

The key requirement is therefore:

Existing cb_subs_inv_* values must be copied/persisted into #__cbsubs_payment_baskets.address_*
Then the mandatory/read-only invoice-address validation can run
If the profile values are truly missing, then payment should be blocked
But if the profile values exist, the basket should not fail just because the snapshot was not initialized
 

Following my previous message, i thought of another approach...
While reviewing the available basket-related triggers, I noticed that CB Auto Actions exposes the basket object in triggers such as:

• Code:

  onCPayBeforeComputeTotalizersPaymentBasketUpdated
• Code:

  onCPayBeforeStorePaymentBasketUpdated
• Code:

  onCbSubsBeforePaymentBasket

Would it theoretically be safe to use one of these triggers to populate missing basket fields from the already-existing profile fields before VAT/totalizers are computed?

I am asking because this could potentially act as a workaround for cases where the basket invoice snapshot may not have been initialized/persisted correctly during basket creation.

For example, in , the basket object ($this) already exists before VAT calculation runs. So in theory it might be possible to detect:

• empty
  Code:

  address_country
• empty
  Code:

  address_country_code
• empty basket invoice fields

and populate them from the user’s existing profile values before tax calculation/payment submission continues.I mainly want to confirm whether this would be considered safe/supported in the CBSubs basket lifecycle, or whether modifying the basket at that stage could cause side effects or conflicts with internal initialization logic.

Ok, I think I understand you workflow pretty clearly. Thank you!

Existing cb_subs_inv_* values must be copied/persisted into #__cbsubs_payment_baskets.address_*
Then the mandatory/read-only invoice-address validation can run
If the profile values are truly missing, then payment should be blocked
But if the profile values exist, the basket should not fail just because the snapshot was not initialized

Below are a few things I'll be looking to implement. All of them being optional of course.

1. Read Only mode making invoice address only editable if cb_subs_inv_* is NULL. So empty basically.
2. Improving "CB fields for first invoicing address of customer" with an option to synchronize on every new basket instead of only on first basket.
3. Potentially exposing cb_subs_inv_* fields to CB itself so those can just be used instead of needing to do any kind of synchronization at all.
4. Option to override the invoice edit URL to send them to profile edit or whatever page you want regarding supplying invoice address.
5. Investigate possible bug with basket invoice address not populating correctly.

I'll work through a few things to see if I can find a simple quick implementation that'd work with your workflow better. It's possible this is just a little bug to be fixed and everything will be fine.

The synchronization from cb_subs_inv_* to basket should work fine as long as cb_subs_inv_last_name or cb_subs_inv_address_country has a value. That's the only requirement.

Would it theoretically be safe to use one of these triggers to populate missing basket

Yes, that's possible. A code action on onCPayBeforeStorePaymentBasketUpdated could work since that's fired after basket has been initialized and before being stored. Its variables are as follows.

var1 being the basket itself. Regardless will be investigating this further as it shouldn't be able to create baskets with empty invoice addresses when cb_subs_inv_* was populated.

Regarding this part of your reply:

"The synchronization from cb_subs_inv_* to basket should work fine as long as cb_subs_inv_last_name or cb_subs_inv_address_country has a value. That's the only requirement."

I may have found an important clue related to this.

In our registration workflow, we populate the country/address-related cb_subs_inv_* fields during approval, but we do not populate cb_subs_inv_first_name and cb_subs_inv_last_name at registration because we do not yet have the buyer’s real PayPal name.

Those name fields are populated only after the first PayPal payment attempt, using the payer name returned by PayPal.

So the sequence currently looks like this:

Before first payment:

cb_subs_inv_address_country = populated
cb_subs_inv_address_city/state = populated
cb_subs_inv_first_name = NULL
cb_subs_inv_last_name = NULL

After first PayPal payment:

cb_subs_inv_first_name / cb_subs_inv_last_name become populated from PayPal payer details

This seems consistent with what we observed:

first basket/payment attempt may end up with NULL basket invoice fields and NULL VAT
second basket/payment attempt for the same user works correctly

What is not fully clear to me is whether missing cb_subs_inv_first_name / cb_subs_inv_last_name could still interfere with basket invoice-address initialization somewhere in the workflow, even if cb_subs_inv_address_country already has a value.

As a possible workaround on our side, we could populate placeholder values such as:

cb_subs_inv_first_name = Not
cb_subs_inv_last_name = declared

during registration approval, and later overwrite them with the real payer name returned by PayPal after payment.

Would this be considered safe/compatible with the CBSubs basket synchronization logic?

It requires last name or country. If either are supplied it should map fine. You're currently providing country so it should be fine. Regardless I'm currently in the process of completely redoing this logic in the basket so it can more reliably synchronize between cb_subs_inv_* and the basket. Ideally once this is done you shouldn't even need your auto action anymore for cb_subs_inv_* and can just let CBSubs handle it.

Was able to make quite a few improvements to the synchronization logic. Below is what you'd see if you've invoice address display turned off. Notice that you can now configure the fields. Those previously were hidden however despite them being hidden in the parameters they are still processed in the code. So now that is fixed.

 

This means you'll be able to map to your fields while keeping invoice address display and edit turned off. Next is being able to always synchronize. Notice the new "Synchronize on". It defaults to the current logic of only on first invoice. It has another option for always synchronizing so on every new basket it'll pull from your fields and push into cb_subs_inv_* all of which pushes into the basket.

In addition to this the field synchronization logic itself now properly calls getFields API. This is a big deal since it allows you to synchronize even from Code or Query fields safely if you wanted. Previously it would only work with fields that explicitly stored values in _comprofiler.

Even if you choose not to use the synchronization parameters the core behavior of passing from cb_subs_inv_* into basket was made substantially more reliable, but I strongly recommend using those parameters instead of the auto action once released.

Will work on adding the feature ticket and getting the MR ready. Hopefully can have the improvements out later today or by end of this week.

forge.joomlapolis.com/issues/9870