Also I prefer to rename that entities to PaymentGatewayPayflowPro,
PaymentGatewayCyberSource.
If anyone disagree with that I proceed in that way and when it will be
ready open a new JIRA issue.
Thanks
Marco
Il giorno 01/apr/09, alle ore 21:41, David E Jones ha scritto:
Adding a prefix wo
Adding a prefix would make finding these entities easier. We didn't do
that with others like Party/Person and ContactMech/PostalAddress, but
yes we certainly could.
-David
On Apr 1, 2009, at 3:38 AM, mrisal...@libero.it wrote:
Ok, thanks a lot for those important clarification.
I will c
As far as I understand it, and my knowledge at this point is very limited as I
am just starting to dig into it, you swap the credit card number with a token
and then the credit card details are stored on a remote server that is already
PCI compliant. This then allows you to reduce the level of P
Sam Hamilton wrote:
> Just starting down the path of PCI, so when I know more I will
> let the list know. I was more thinking of getting compliance
> by moving the storage of credit cards out of the database and
> into the payment processors servers (secure storage based on
> tokens)
How would rep
Just starting down the path of PCI, so when I know more I will let the list
know. I was more thinking of getting compliance by moving the storage of credit
cards out of the database and into the payment processors servers (secure
storage based on tokens)
On 01/04/2009 03:35, "BJ Freeman" wrot
Ok, thanks a lot for those important clarification.
I will create a new JIRA issue and a patch for it as soon as I can.
Antoher small question :
did you think that it's better to have a PayflowPro entity or put a prefix
before it (ex. PaymentGatewayPayflowPro, PaymentGatewayCyberSource, ...) ?
So
Yes, this looks much better Marco, and is just the direction I was
trying to communicate.
There are a few things you could do to clarify the structure, and make
it more consistent with other sets of entities that are using the type/
etc pattern:
1. make a PaymentGatewayConfigType entity
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I am wondering how a PCI audit might view having certificates and login
info in a database.
I know that securing the database is one option. there has been a effort
to beef up security through ofbiz.
Just something to consider.
I have no info one way o
Anyway I made I mistake in the above example because Payflow Pro is a
credit card payment gateway and so it's not necessary a new payment
method type (EXT_PAYFLOW).
So the corrected example is the following:
description="Payment Gateway"/>
enumCode="PAYFLOWPRO" sequenceId="1" descr
Hi David,
thanks a lot for your great analysis help on this, I have now understood what
you mean after trying those new entities.
Also I prefer now to implement those specific entities instead of generic ones.
If I understood correctly it could be something similar to the following
examples:
On Mar 30, 2009, at 9:38 PM, Adam Heath wrote:
David E Jones wrote:
This has been discussed a few times and I think is on a few of the
lists
around were people have brainstormed on things they'd like to
add/change/etc. I'm personally very in favor of it and I do believe
it
has been need
David E Jones wrote:
>
> This has been discussed a few times and I think is on a few of the lists
> around were people have brainstormed on things they'd like to
> add/change/etc. I'm personally very in favor of it and I do believe it
> has been needed for a long time.
Why not add support in the
This has been discussed a few times and I think is on a few of the
lists around were people have brainstormed on things they'd like to
add/change/etc. I'm personally very in favor of it and I do believe it
has been needed for a long time.
As for the design, I'm very against the concept of
+1 - this is one of many of these types of things that would be great if we
moved to the db. Not sure of the entities at this point, but I'm all for the
change.
Cheers,
Tim
--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com
o:801.649.6594
f:801.649.6595
- mrisal...@libero.it wrote:
>
Hi to all,
what did you think if we move the payment.properties to an entity ?
I tried to having a more general entity but I have seen that every single
payment gateway having different parameters and so I tried with the following
example:
Once we have it into the DB i
15 matches
Mail list logo