Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #7939 > unrolled thread

Refunding PayPal payments for a SaaS

Back to article view | Back to comp.programming

Contents

  Refunding PayPal payments for a SaaS Victor Porton <porton@narod.ru> - 2017-07-25 19:21 +0300
    Re: Refunding PayPal payments for a SaaS Julio Di Egidio <julio@diegidio.name> - 2017-07-25 10:48 -0700
      Re: Refunding PayPal payments for a SaaS Victor Porton <porton@narod.ru> - 2017-07-26 01:37 +0300
        Re: Refunding PayPal payments for a SaaS Julio Di Egidio <julio@diegidio.name> - 2017-07-25 18:20 -0700
          Re: Refunding PayPal payments for a SaaS Victor Porton <porton@narod.ru> - 2017-07-26 15:02 +0300
            Re: Refunding PayPal payments for a SaaS Ed Prochak <edprochak@gmail.com> - 2017-07-26 19:59 -0700

#7939 — Refunding PayPal payments for a SaaS

We are building a SaaS paid with PayPal.

We process PayPal's notifications for payments, subscriptions, and canceling 
subscriptions.

Should we also process refunds (automatically canceling a service if its 
payment was refunded)?

There is a reason not to: Refunds may happen in the case we do an error in 
our payment processing system or a race condition. In this case refund 
should not cancel the service, for obvious reasons.

What are further arguments pro and counter to cancel or not to cancel a 
service automatically in the case of a refund?

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]

#7940

On Tuesday, July 25, 2017 at 6:21:25 PM UTC+2, Victor Porton wrote:
> We are building a SaaS paid with PayPal.
> 
> We process PayPal's notifications for payments, subscriptions, and canceling
> subscriptions.
> 
> Should we also process refunds (automatically canceling a service if its 
> payment was refunded)?
> 
> There is a reason not to: Refunds may happen in the case we do an error in 
> our payment processing system or a race condition. In this case refund 
> should not cancel the service, for obvious reasons.
> 
> What are further arguments pro and counter to cancel or not to cancel a 
> service automatically in the case of a refund?

The logic of payments/refunds and the logic of services should be
independent.  On a side, you can have up to complicated payment/refund
schemes including discounts and offers.  On the other, you can have active
vs suspended vs cancelled services, and so on.  In general, the fact that
some (plural) payments/refunds may (or may not) correspond to some (plural)
service status changes is in fact a higher-level relationship, call it a
"user transaction" (you may find a better name/abstraction more suited to
your domain).

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#7942

Julio Di Egidio wrote:

> On Tuesday, July 25, 2017 at 6:21:25 PM UTC+2, Victor Porton wrote:
>> We are building a SaaS paid with PayPal.
>> 
>> We process PayPal's notifications for payments, subscriptions, and
>> canceling subscriptions.
>> 
>> Should we also process refunds (automatically canceling a service if its
>> payment was refunded)?
>> 
>> There is a reason not to: Refunds may happen in the case we do an error
>> in our payment processing system or a race condition. In this case refund
>> should not cancel the service, for obvious reasons.
>> 
>> What are further arguments pro and counter to cancel or not to cancel a
>> service automatically in the case of a refund?
> 
> The logic of payments/refunds and the logic of services should be
> independent.  On a side, you can have up to complicated payment/refund
> schemes including discounts and offers.  On the other, you can have active
> vs suspended vs cancelled services, and so on.  In general, the fact that
> some (plural) payments/refunds may (or may not) correspond to some
> (plural) service status changes is in fact a higher-level relationship,
> call it a "user transaction" (you may find a better name/abstraction more
> suited to your domain).

Even if so, we need to write software which automatically subscribe on 
payment. Should it also automatically unsubscribe on refund?

> HTH,
> 
> Julio
-- 
Victor Porton - http://portonvictor.org

[toc] | [prev] | [next] | [standalone]

#7943

On Wednesday, July 26, 2017 at 12:37:16 AM UTC+2, Victor Porton wrote:
> Julio Di Egidio wrote:
> > On Tuesday, July 25, 2017 at 6:21:25 PM UTC+2, Victor Porton wrote:
> >> We are building a SaaS paid with PayPal.
> >> 
> >> We process PayPal's notifications for payments, subscriptions, and
> >> canceling subscriptions.
> >> 
> >> Should we also process refunds (automatically canceling a service if its
> >> payment was refunded)?
> >> 
> >> There is a reason not to: Refunds may happen in the case we do an error
> >> in our payment processing system or a race condition. In this case refund
> >> should not cancel the service, for obvious reasons.
> >> 
> >> What are further arguments pro and counter to cancel or not to cancel a
> >> service automatically in the case of a refund?
> > 
> > The logic of payments/refunds and the logic of services should be
> > independent.  On a side, you can have up to complicated payment/refund
> > schemes including discounts and offers.  On the other, you can have active
> > vs suspended vs cancelled services, and so on.  In general, the fact that
> > some (plural) payments/refunds may (or may not) correspond to some
> > (plural) service status changes is in fact a higher-level relationship,
> > call it a "user transaction" (you may find a better name/abstraction more
> > suited to your domain).
> 
> Even if so,

There is no contrast between what I have explained, which is in general,
and the specific problem you are trying to solve, which might just end
up simplifying relative to the general case.  In general, a use case
splits into tasks and sub-tasks, each of which in turn may leverage some
components or services over possibly a collection of business objects:
and you are essentially talking about flattening the whole hierarchy,
which is sensible if and only if the hierarchy is flat to begin with...

> we need to write software which automatically subscribe on 
> payment.  Should it also automatically unsubscribe on refund?

- Do you mean that your system just receives a notification of payment
(say, from the finance department's system) upon which it automatically
will subscribe the corresponding user?

- Do you mean that your system just receives a notification of refund
(say, from the finance department's system) upon which it automatically
will unsubscribe the corresponding user?

If that is *all* that happens in your system, sure go for it, though then
I cannot really guess why you were having any doubt to begin with: indeed,
that means that your system just knows nothing about any payments/refunds,
rather some external system is telling it "subscribe this user" or
"unsubscribe this user", and that's all there is to it.

And you are certainly welcome to refine your description and question at
this point, I have been totally guessing about your actual requirements,
but my point is more to show you how to think and go about it: this is
analysis, where ultimately you have to answer your own questions...

Julio

[toc] | [prev] | [next] | [standalone]

#7944

Julio Di Egidio wrote:

> On Wednesday, July 26, 2017 at 12:37:16 AM UTC+2, Victor Porton wrote:
>> Julio Di Egidio wrote:
>> > On Tuesday, July 25, 2017 at 6:21:25 PM UTC+2, Victor Porton wrote:
>> >> We are building a SaaS paid with PayPal.
>> >> 
>> >> We process PayPal's notifications for payments, subscriptions, and
>> >> canceling subscriptions.
>> >> 
>> >> Should we also process refunds (automatically canceling a service if
>> >> its payment was refunded)?
>> >> 
>> >> There is a reason not to: Refunds may happen in the case we do an
>> >> error in our payment processing system or a race condition. In this
>> >> case refund should not cancel the service, for obvious reasons.
>> >> 
>> >> What are further arguments pro and counter to cancel or not to cancel
>> >> a service automatically in the case of a refund?
>> > 
>> > The logic of payments/refunds and the logic of services should be
>> > independent.  On a side, you can have up to complicated payment/refund
>> > schemes including discounts and offers.  On the other, you can have
>> > active
>> > vs suspended vs cancelled services, and so on.  In general, the fact
>> > that some (plural) payments/refunds may (or may not) correspond to some
>> > (plural) service status changes is in fact a higher-level relationship,
>> > call it a "user transaction" (you may find a better name/abstraction
>> > more suited to your domain).
>> 
>> Even if so,
> 
> There is no contrast between what I have explained, which is in general,
> and the specific problem you are trying to solve, which might just end
> up simplifying relative to the general case.  In general, a use case
> splits into tasks and sub-tasks, each of which in turn may leverage some
> components or services over possibly a collection of business objects:
> and you are essentially talking about flattening the whole hierarchy,
> which is sensible if and only if the hierarchy is flat to begin with...
> 
>> we need to write software which automatically subscribe on
>> payment.  Should it also automatically unsubscribe on refund?
> 
> - Do you mean that your system just receives a notification of payment
> (say, from the finance department's system) upon which it automatically
> will subscribe the corresponding user?
> 
> - Do you mean that your system just receives a notification of refund
> (say, from the finance department's system) upon which it automatically
> will unsubscribe the corresponding user?

Yes.

> If that is *all* that happens in your system, sure go for it, though then
> I cannot really guess why you were having any doubt to begin with: indeed,
> that means that your system just knows nothing about any payments/refunds,
> rather some external system is telling it "subscribe this user" or
> "unsubscribe this user", and that's all there is to it.
> 
> And you are certainly welcome to refine your description and question at
> this point, I have been totally guessing about your actual requirements,
> but my point is more to show you how to think and go about it: this is
> analysis, where ultimately you have to answer your own questions...
> 
> Julio
-- 
Victor Porton - http://portonvictor.org

[toc] | [prev] | [next] | [standalone]

#7946

On Wednesday, July 26, 2017 at 8:14:25 AM UTC-4, Victor Porton wrote:
> Julio Di Egidio wrote:
> 
[]
> > 
> >> we need to write software which automatically subscribe on
> >> payment.  Should it also automatically unsubscribe on refund?
> > 
> > - Do you mean that your system just receives a notification of payment
> > (say, from the finance department's system) upon which it automatically
> > will subscribe the corresponding user?
> > 
> > - Do you mean that your system just receives a notification of refund
> > (say, from the finance department's system) upon which it automatically
> > will unsubscribe the corresponding user?
> 
> Yes.
> 
[]
> -- 
> Victor Porton - http://portonvictor.org

Hi victor,

This sounds very simplistic. As Julio mentioned, if that is
how you business works, do it. I am struggling to think what
business this might be. Something like an on-line jukebox where
you make a paypal payment, then a song plays. But then I cannot
think of a refund scenario.

Do you have anyone with any accounting experience in your company?
(I am assuming this is a startup.)

Let's say it's a magazine style service. you pay for a year and
get the articles regularly. About 6months you decide to cancel,
so you expect a refund for the undelivered service. (That still
doesn't match what you said was your business model.)

Anyway, I am confused about your requirements. Maybe you are
also confused. I suggest, sitting down and writing the steps you
would follow if you were doing the entire system manually.
Who are the players involved? (Customers are players, treat
the software as players too.) Write out each possible scenario,
identifying the players involved and the actions they each take,
and the interactions (interfaces) they have.

I hope that helps.
  ed

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web