Using Stripe Upcoming Invoice to preview changes in subscription - stripe-payments

I want to use Stripe Upcoming Invoices to display how much a user will be billed when he makes changes to his subscriptions. But it seems that I miss something...
Why do I get 29 instead of 0?
dump($plans['basic_monthly']->price);
29.0
dump($plans['premium_monthly']->price);
49.0
$stripe_customer = step1_create_customer();
$stripe_subscription = step2_create_subscription($stripe_customer, $plans['basic_monthly']->stripe_price_id);
dump([
'reason' => 'Nohting was changed (price_id and quantity are the same), so 0 is expected. Why 29 is here?',
'expected' => 0,
'actual' => upcoming($stripe_subscription, $plans['basic_monthly']->stripe_price_id)->amount_due/100,
]);
array:3 [▼
"reason" => "Nohting was changed (price_id and quantity are the same), so 0 is expected. Why 29 is here?"
"expected" => 0
"actual" => 29
]
dump([
'reason' => 'Transition to more expensive plan was made. 49 - 29 = 20 is expected',
'expected' => 20,
'actual' => upcoming($stripe_subscription, $plans['premium_monthly']->stripe_price_id)->amount_due/100,
]);
array:3 [▼
"reason" => "Transition to more expensive plan was made. 49 - 29 = 20 is expected"
"expected" => 20
"actual" => 20
]
function step1_create_customer()
{
$stripe = new \Stripe\StripeClient(env('STRIPE_SECRET_KEY'));
$test_clock = $stripe->testHelpers->testClocks->create([
'frozen_time' => time(),
'name' => sprintf('Testing Upcoming Invoices'),
]);
$stripe_customer = $stripe->customers->create([
'test_clock' => $test_clock->id,
'payment_method' => 'pm_card_visa',
'invoice_settings' => ['default_payment_method' => 'pm_card_visa'],
'metadata' => [
'testing_upcoming_invoices' => 1,
],
'expand' => [
'test_clock',
'invoice_settings.default_payment_method',
],
]);
return $stripe_customer;
}
function step2_create_subscription($stripe_customer, $stripe_price_id)
{
$stripe = new \Stripe\StripeClient(env('STRIPE_SECRET_KEY'));
$stripe_subscription = $stripe->subscriptions->create([
'customer' => $stripe_customer->id,
'items' => [
[
'price' => $stripe_price_id,
'quantity' => 1,
],
],
'metadata' => [
'testing_upcoming_invoices' => 1,
],
]);
return $stripe_subscription;
}
function upcoming($stripe_subscription, $stripe_price_id)
{
$stripe = new \Stripe\StripeClient(env('STRIPE_SECRET_KEY'));
$stripe_invoice = $stripe->invoices->upcoming([
'subscription' => $stripe_subscription->id,
'subscription_items' => [
[
'id' => $stripe_subscription->items->data[0]->id,
'price' => $stripe_price_id,
'quantity' => 1,
],
],
'subscription_cancel_at_period_end' => false,
'subscription_proration_behavior' => 'always_invoice',
//'subscription_proration_date' => $now,
]);
return $stripe_invoice;
}

What your code is doing here is upgrading a Subscription from Price A ($29/month) to Price B ($49/month) immediately after creation. You're also passing subscription_proration_behavior: 'always_invoice'.
When you upgrade or downgrade a subscription, Stripe calculates the proration for you automatically. This is something Stripe documents in details here and here.
In a nutshell, since you move from $29/month to $49/month immediately after creation, what happens is that Stripe calculates that:
You owe your customer credit for the time they paid on $29/month that they won't use. Since it's immediately after creation, you owe them $29.
The customer owes you for the remaining time for the new Price. Since it's the start of the month they owe you the full price of $49.
In a default integration, the proration is created as 2 separate InvoiceItems that are pending until the next cycle. In your case you pass proration_behavior: 'always_invoice' so an Invoice is created immediately with only those 2 line items. -$29 + $49 = $20 which is where the amount comes from.

Related

Stripe Subscription Schedule Testing

1:How can I test and trigger subscription scheduled.
$plan = Plan::create([
'currency' => $currency,
'interval' => 'day',
'product' => $product,
'amount' => $amount
]);
$schedule = SubscriptionSchedule::create([
'customer' => $customer_id,
'start_date' => 'now',
'end_behavior' => 'release',
'phases' => [
[
'plans' => [
[
'price' => $plan->id,
'quantity' => 1,
],
],
'iterations' => 3,
'collection_method'=> 'charge_automatically'
],
],
]);
return $schedule;
So I create a subscription today, how I can test. Also when creating plan we can only specify billing frequency as either day, week, month or year.
Have already tried updating subscription Id with params
setting trial_end: Few seconds from now
prorate: false
But this creates invoice for the same month. Also its creates another invoice with amt:0.(Dont know why it created).
2: Is this the same approach for testing subscription schedule.
I use Stripe's Test Clocks. Basically you simulate progress of time by setting a date and time in the future in order to make your subscriptions happen. Unfortunately you cannot use your existing Test Subscriptions and Customers but you have to create them just for the specific simulation.

DocuSign Api creating envelope in Production

I have a problem with creating Envelope through the Api.
The authorization is performed without errors.
$options = new \DocuSign\eSign\Api\AuthenticationApi\LoginOptions();
$loginInformation = $authenticationApi->login($options);
I get this in response:
LoginInformation {
#container: array:2 [
"api_password" => null
"login_accounts" => array:1 [
0 => LoginAccount {
#container: array:11 [
"account_id" => "xxxxx"
"account_id_guid" => null
"base_url" => "https://na2.docusign.net/restapi/v2/accounts/xxxxx"
"email" => "xxxxx#xxxxxx.com"
"is_default" => "true"
"login_account_settings" => null
"login_user_settings" => null
"name" => "xxxxxxx, LLC"
"site_description" => ""
"user_id" => "xxxxxxxxxxxxxxxxxxx"
"user_name" => "xxxxxx Contracts Team"
]
}
]
]
}
But when I’m trying to create the Envelope this way:
$envelopeApi->createEnvelope($this->config->getAccountId(), $envelop_definition, $options);
I get this error: «[401] Error connecting to the API (https://www.docusign.net/restapi/v2/accounts/xxxxx/envelopes)”
This error notifies me that I’m not authorized. This code works properly in Sandbox.
I think that the problem is in settings of account - maybe there is a lack of special rights...
You need to use the right production platform. The right production platform is determined by the DocuSign Account ID.
See step 1 in the Post Go Live document.

Sensu subdue alerts outside working hours and weekends

I want to subdue some sensu checks outside working hours and weekends. The documentation is not clear on how it works. Sensu subdue documentation
'subdue' => {
'days' => {
'all' => [
{
'begin' => '8:00 PM',
'end' => '10:00 AM'
}
],
'saturday' => [
{
'begin' => '12:00 AM',
'end' => '11:59 PM'
}
],
'sunday' => [
{
'begin' => '12:00 AM',
'end' => '11:59 PM'
}
]
}
}
My question is: will the specific day override the all attribute?
Also: is there a better way to do this check?
Thanks!
Yes, Specific day override all attribute. We should add subdue configurations in our client.json file.

HornetQ : How to read DLQ details

I would like to read the number of messages sent to the DLQ in hornetq.
Using CLI commands, the jms.queue.DLQ does not appear after :
/subsystem=messaging/hornetq-server=default/jms-queue=
Even if it's configured as DLQ for the testQueue
{
"outcome" => "success",
"result" => {
"consumer-count" => 0,
"dead-letter-address" => "jms.queue.DLQ",
"delivering-count" => 0,
"durable" => true,
"entries" => [
"queue/test",
"java:jboss/exported/jms/queue/test"
],
"expiry-address" => "jms.queue.ExpiryQueue",
"message-count" => 0L,
"messages-added" => 0L,
"paused" => false,
"queue-address" => "jms.queue.testQueue",
"scheduled-count" => 0L,
"selector" => undefined,
"temporary" => false
}
}
Enviroment: jboss 6.0
Thanks.
The DLQ does not appear because is just an address and not a physical destination. The same situation occurs with the ExpiryQueue. You have to create first these 2 queues. Please find below the corresponding CLI commands:
/subsystem=messaging/hornetq-server=default/jms-queue=deadLetterQueue:add(entries=["queue/deadLetterQueue"],durable=false)
/subsystem=messaging/hornetq-server=default/jms-queue=expiryQueue:add(entries=["queue/expiryQueue"],durable=false)

logstash calculate elapsed time not working

I have file containing series of such messages:
component+branch.job 2014-09-04_21:24:46 2014-09-04_21:24:49
It is string, some white spaces, first date and time, some white spaces and second date and time. Currently I'm using such filter:
grok {
match => [ "message", "%{WORD:componentName}\+%{WORD:branchName}\.%{DATA:jobType}\s+20%{DATE:dateStart}_%{TIME:timeStart}\s+20%{DATE:dateStop}_%{TIME:timeStop}" ]
}
mutate {
add_field => {"tmp_start_timestamp" => "20%{dateStart}_%{timeStart}"}
add_field => {"tmp_stop_timestamp" => "20%{dateStop}_%{timeStop}"}
}
date {
match => [ "tmp_start_timestamp", "YYYY-MM-dd_HH:mm:ss" ]
add_tag => [ "jobStarted" ]
}
date {
match => [ "tmp_stop_timestamp", "YYYY-MM-dd_HH:mm:ss" ]
target => "stop_timestamp"
remove_field => ["tmp_stop_timestamp", "tmp_start_timestamp", "dateStart", "timeStart", "dateStop", "timeStop"]
add_tag => [ "jobStopped" ]
}
elapsed {
start_tag => "jobStarted"
end_tag => "jobStopped"
unique_id_field => "message"
}
As result I receive "#timestamp" and "stop_timestamp" fields with date time data and two tags, without elapsed time calculation. What I'm missing?
UPDATE
I tried with splitting (as #Rumbles suggested) event on two separate events, but somehow logstash creates two the same events:
input {
stdin { type => "time" }
}
filter {
grok {
match => [ "message", "%{WORD:componentName}\+%{WORD:branchName}\.%{DATA:jobType}\s+20%{DATE:dateStart}_%{TIME:timeStart}\s+20%{DATE:dateStop}_%{TIME:timeStop}" ]
}
mutate {
add_field => {"tmp_start_timestamp" => "20%{dateStart}_%{timeStart}"}
add_field => {"tmp_stop_timestamp" => "20%{dateStop}_%{timeStop}"}
update => [ "type", "start" ]
}
clone {
clones => ["stop"]
}
if [type] == "start" {
date {
match => [ "tmp_start_timestamp", "YYYY-MM-dd_HH:mm:ss" ]
target => ["start_timestamp"]
add_tag => [ "jobStarted" ]
}
}
if [type] == "stop" {
date {
match => [ "tmp_stop_timestamp", "YYYY-MM-dd_HH:mm:ss" ]
target => "stop_timestamp"
remove_field => ["tmp_stop_timestamp", "tmp_start_timestamp", "dateStart", "timeStart", "dateStop", "timeStop"]
add_tag => [ "jobStopped" ]
}
}
elapsed {
start_tag => "jobStarted"
end_tag => "jobStopped"
unique_id_field => "message"
timeout => 15
}
}
output {
stdout { codec => rubydebug }
}
I've never used this filter, however I have just had a quick read of the documentation, and I think I understand the issue you are having.
From your description I believe you are trying to run the elapsed filter on one event, from the documentation it would appear that the filter is expecting 2 events, one with the starting time the second with the ending time, with a common id helping the filter to identify when the 2 events match up:
The events managed by this filter must have some particular properties. The event describing the start of the task (the “start event”) must contain a tag equal to ‘start_tag’. On the other side, the event describing the end of the task (the “end event”) must contain a tag equal to ‘end_tag’. Both these two kinds of event need to own an ID field which identify uniquely that particular task. The name of this field is stored in ‘unique_id_field’.
Each message is considered an event, so you would need to split your messages in to two events and have each pair of events have a unique identifier to help the filter to link them back together. It's not exactly a tidy solution (split your event in to two events, and then reconnect them again later) there may be a better solution to this that I am not aware of.

Resources