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.