"PAID" Button does not appear to do anything: Prepaid Account

@devangn

I have made a prepaid test account, then assigned a product with a price of 19.99 monthly.

As you see from the image, the product has been applied, and showing a balance of negative -19.99.

Then going into Billing → invoices.

Since there are different means to pay, I tried clicking the PAID button, but nothing happens.

Looking at the Debug logs, I am seeing:

ERROR - 2023-08-21 17:52:02 → Severity: Notice → Trying to access array offset on value of type bool /opt/ASTPP/web_interface/astpp/application/libraries/Usertracking.php 167

Also, this may not be related, but I am also seeing this just by loading the invoice page:

ERROR - 2023-08-21 17:51:23 → Severity: Notice → Undefined index: billseconds /opt/ASTPP/web_interface/astpp/application/models/common_model.php 204

Bug Report time?

The ‘Paid’ is label/flag, not button

Thanks for the clarification.

However, there has been no type of payment made, and the status page shows:

And when attempting to make a call the FreeSwitch CLI shows insufficient credit.

The test “Product” I created gives 10,000 Free Minutes.

It seems then the Paid label is showing an incorrect payment made.

Note: The “Paid” label appears identical to actual other buttons. Look at “Notify” and “View All” Above. Maybe it needs to look different?

Also, what about the ASTPP errors?

Yes, the design of label should be different to avoid and misunderstanding. Please log the suggestion.
About package and ‘no sufficient fund’ message, are you dialling the number starting the same prefix as you have added in the created and assigned package?

Yes I am doing that. That still leaves the issue of conflicting balances with one showing paid, and the other negative balance. So which is correct?

As I mentioned, I am still seeing two errors:

ERROR - 2023-08-25 00:00:34 --> Severity: Notice  --> Undefined index: billseconds /opt/ASTPP/web_interface/astpp/application/models/common_model.php 204
ERROR - 2023-08-25 00:00:34 --> Severity: Notice  --> Trying to access array offset on value of type bool /opt/ASTPP/web_interface/astpp/application/libraries/Usertracking.php 224

Could those have an effect on the issue?

Also, suggestion of making a change to PAID, which also so happens to even act like a button which does nothing. That is the reason for opening this thread in the first place.

https://jira.astppbilling.org/browse/ASTPPCOM-1397

Please share fs logs pastebin and package configuration screen shot.

Here is a sanitized pastebin fs_cli

And a screenshot of the package configuration

Update Since posting: I think I see part of my problem.

I forgot to add a destination available for the package which I have since added.

I am no longer getting the insufficient funds error, but still brings me back to how the package was paid for, and why the low balance still exists on the main page.

Also, while the previous problem has gone away, I am seeing a new issue related to making the same call.

mod_dptools.c:3637 Originate Failed. Cause: INCOMPATIBLE_DESTINATION

Perhaps I can figure the incompatible destination issue out before you respond again

About package purchase, how did you purchased, meaning paid while your have purchased it from customer potall?
Incompatible_destination has to do with codec negotiation

1 Like

It was added to a preexisting account after the package was created. That drop down box which has “Apply to existing accounts.”

Thank you, I will look into that.

Update:

Not sure were this is coming from. The log shows:

 mod_dptools.c:3637 Originate Failed.  Cause: INCOMPATIBLE_DESTINATION

I am using a softphone which does have uLAW and aLAW enabled. I am also using the default SIP Profile which I see it is using PCMA & PCMU. As well, the gateway is also set up to use PCMA & PCMU.

Update 2: Using sngrep, I see the source of the issue is actually coming from the provider. It is responding with SIP/2.0 488 Not acceptable here. I guess I will have to get with them to see what the issue could be.

I guess the issue leftover for now is how the plan was paid for without payment. In addition, the period of the product of 30 days has long expired. Maybe time for a new thread on that?

Update 3: The call fail issue is with the provider which I am trying to resolve now. That still leaves the unpaid/paid balance issue, and package has gone over 30 days.

In the log, I saw this:

2023-09-01 22:12:43.012567 98.73% [NOTICE] switch_cpp.cpp:1465 [ASTPP] Actual Balance : -19.99
2023-09-01 22:12:43.012567 98.73% [NOTICE] switch_cpp.cpp:1465 [ASTPP] Allocating static balance for package calls, Balance : 100, Credit limit : 200
2023-09-01 22:12:43.012567 98.73% [NOTICE] switch_cpp.cpp:1465 [ASTPP] package_id : 1

So, I am seeing conflicting information. Balance is not paid, but for some reason, it is PAID on the main page. and a balance of 100, with a credit limit of 200 on a prepaid account.

Thanks for responding.

@KNERD
This static balance and credit limit are ‘static’ not ‘real-time or dynamic’, the reason is that further logic can consider the available balance or credit limit for the account which is having package active for the dialed destination and can allow the call to pass instead checking its actual balance or credit limit.

About the case of package purchase without balance, that cannot be done, and its working as it should be, now to check how it happened in your case, can you reproduce it and share exact step you are following?

As mentioned, this testing was done on a PREPAID account.

It should not have any credit, or am I incorrect? I tried adding a credit limit to it, but I was unable to. That is why I put in the suggestion for a hybrid account of being prepaid with some calling being postpaid.

For the package purchase, as I mentioned before, during creation I had the YES selected for “Apply on Existing Accounts” during the Product creation.

image