## 支付流程设计 以及细节安全 业务场景：一个预定可以首次预定，还可以在预定有效期内对其进行多次续订。 目标：设计一个高效，友好，安全的支付方案流程。 >[tip] 注意：无论哪种方案，用户都有可能打开多个窗口，生成多个支付二维码支付 **需要注意问题：** 1. 数据一致性校验（防止用户在过期的界面提交，这样会造成实际生成的订单金额等数据可能与用户在点击提交前的页面上看到的不一致，会让用户感到困惑） 2. 安全校验（防止用户篡改信息，一般是保护订单等信息不被非法篡改） 3. 并发问题（用户同时打开多个页面进行操作，生成多个订单，造成多支付二维码重复支付的问题） **安全，防止并发问题需确保：** 1. 保证同一预定同一时刻只能被一个线程进行操作（包括预定下面的资源，订单等） 2. 每次创建订单，都会检查当前预定状态是否满足创建订单，并将名下其他待支付的订单标记为失效 3. 收到支付回执时检查预定和订单的状态是否分别满足状态，以及状态是否相互吻合，如：预定是否为待支付或生效中（预定待支付时订单类型应该是预定订单，预定生效中时订单类型应该是预定订单），订单是否失效了，失效则安排退款等 ***** **方案一：** 1. 获取价格信息，根据其显示界面，表单 2. 点击确认，提交表单生成订单，根据订单生成支付二维码，并返回支付信息 > 选择价格时不创建订单，等确认提交时，一次性生成订单和支付信息 >[tip] 需要注意的地方：以最后生成订单的时刻为准来做数据校验 ---- **方案二：** 1. 获取价格信息，自动创建订单（每次天数选择都会自动生成新的订单） 2. 点击支付按钮，根据前次的订单信息生成支付二维码 > 选择价格时就创建订单，每次返回订单信息，点击“提交”按钮时，根据前次的订单信息生成支付信息 >[tip] 需要注意的地方： > 1. 提交时检查订单是否存在，状态是否正确，order_id是否被篡改等； > 2. 如果对数据时效性要求高，还需要对数据一致性进行校验，过期数据，可认为是过期订单，直接作废处理，提示用户页面过期，引导重新生成订单。 > 3. 以最后生成支付信息时为准做数据校验的 ---- **方案三：** 1. 获取价格信息，自动创建订单，并根据订单生成支付二维码 > 选择价格时就创建订单，并根据其订单信息生成支付信息，一并返回，一步到位没有其他提交操作，直接就返回支付信息 > 优点：步骤少，快 >[tip] 缺点/缺陷：由于是直接生成了支付信息，所以无法像方案一和方案二那样做数据过期校验了，**总不能以收到支付回执时的信息为准来做数据校验吧**，（通常以最后生成订单的时刻为准来做数据校验，方案二例外，是以最后生成支付信息时为准做数据校验的），所以如果对过期数据有要求的话，就不能采用此方案。（支付信息也有支付有效期的参数，如果对数据过期不是特别苛刻，也可以用这个） ***** ~~~ 预定类型，预定应该是预定成功的第一个订单，如果不适用预锁定方式的话，订单类型不应该是创建时生成，这样会导致多个预定类型的订单 除非采用预加锁的方式，而不是支付回执成功后才加锁 预加锁也不能解决这个问题，因为订单是每次点击提交都会生成的（同时生成支付信息） 只能在回执时写入订单类型了 这样也还解决不了，别人开多个窗口提交支付，可以绕过系统对于预定次数的限制 所以不能每次点击提交就同时生成订单信息和支付信息，这样不可控 只能获取价格时生成订单信息，点击提交时才根据订单信息生成支付信息，这样就可以控制订单状态了，使得对于一个预定，同时只能存在一个有效的订单，而又可以做到不限制用户可以任意的创建订单，这样就从根源上解决了多订单同时支付的混乱问题了 如果需要做成直接选择价格后直接就能出来支付信息，而不需要多点击一下，就可以做个假二维码让用户点一下刷新，刷新时才是根据订单生成支付信息 ~~~ ~~~ 这样也还是不能解决用户同时打开多个支付二维码支付的问题，只能回执时，检测到订单状态 是关闭取消的状态，就安排退款，还要检测预定状态是否正确 不能彻底解决这个问题，生成新订单时关闭旧订单，回执时处理，目前来看算是最合理最直观的处理方案了 那现在就可以生成支付信息，没必要再提交一次 不过现在生成支付信息也有个问题，那就是不能校验旧数据了（这是个何时生成订单，何时又根据订单生成支付信息的问题） 如果再次提交时生成支付信息，我们就可以以最后生成支付信息的时候为准来校验旧数据（其实支付接口也可以设置过期关闭参数） 每种方案都有它的好处和缺陷，具体视情况而定，如果不过分担心旧数据的情况，可以通过超时关闭支付的来参数控制 如果对旧数据比较严格，时间比较精确实时的话，那么就采用最后生成支付信息的一刻校验数据的方案 ~~~